Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=460304
--- Comment #12 from Yaakov Nemoy <loupgaroublond(a)gmail.com> 2008-09-04 23:11:23 EDT ---
Perhaps I should have been more specific. Jen's macros call 'runhaskell'.
This defaults to the default compiler on any given system. I would prefer we
deliberately called runghc.
Take the following case. User A installs GHC and develops a package. He posts
a spec for review.
User B prefers NHC and has it set up as his default compiler. He downloads the
SRPM and builds it, which automatically gets built with NHC. He then tests it
in mock, and it also works. Mock used GHC. Weird but ok.
User C uses Hugs98, and creates a second package. He doesn't test it in mock,
because sometimes he's lazy. User B downloads the SRPM and tries to build it.
For some odd reason, hugs chokes on it. Weird, and not ok. Then for some
reason, the patch User B figures out makes GHC choke. When the package is
compiled with mock, we have total failure.
This use case rubs against me the wrong way, because we used runhaskell instead
of runghc.
If we use runghc, then all three users will automatically use GHC, and
automatically be working on the same platform. The package will then be named
ghc-* because it was tested on that.
When User B decides both packages should be done up in NHC, and User C decides
hugs98 suits him better, they both copy the macros file, patch the compiler
RPMs, and create nhc-* and hugs98-* variants. The world is a happier place.
To make it absolutely clear, i'm not worried about the content of the macros.
Jen clearly knows what works better than I. I just think, that unless any
particular macro does not depend on the command 'runhaskell', namely can do
things exactly the same way, no matter which compiler is on the system, then we
can prefix it with 'cabal_'. To the best of my knowledge, no macros meet
these requirements. Likewise, the prefix 'haskell_' is also wrong. I would
rather we stick to a consistent ghc- and ghc_ naming scheme.
On a side note, the packages I have submitted for review (the are blocked on
this bug, so you can find them through that reference) were built and tested
using my version. Please be extra careful when testing them with Jens'
version.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=460304
Tom Moertel <tom(a)moertel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tom(a)moertel.com
--- Comment #11 from Tom Moertel <tom(a)moertel.com> 2008-09-04 21:54:47 EDT ---
I suggest everybody compare Jens's updated ghc-X11 spec (A) with the previous
version (B). I scrutinized every change with ediff, and in each case I prefer
the updated version.
A: https://bugzilla.redhat.com/attachment.cgi?id=315734
B: http://ynemoy.fedorapeople.org/repo/ghc-X11.spec
Does anybody see any *technical* problems with Jens's macros? If so, let's get
those problems in the open so we can solve them.
Cheers,
Tom
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=460304
--- Comment #10 from Bryan O'Sullivan <bos(a)serpentine.com> 2008-09-04 21:15:48 EDT ---
I'm willing to give this a few more days to settle out, but Miles is right,
time is of the essence. See below.
Re comment #5:
> 1) the macros should be prefixed with ghc, not cabal or haskell
GHC-specific macros should be prefixed with ghc. Many of the macros provided
by both of you are not specific to GHC.
> 2) library packages should be prefixed with ghc-, not haskell-
I would prefer this approach, too. I do not believe that asking maintainers to
support multiple Haskell implementations will scale.
> Also, I would like to ask that you backport the macros to everything, because
> they are definitely needed in order to build packages.
OK.
I would like to suggest a deadline of next Thursday (Sep 11) to resolve the two
sets of macro files into one. We will have to move quickly afterwards to adapt
to the changes in GHC 6.10.1 if we want to ship that in F10 (which I *very*
much want to do). Those changes include shared library support, so the amount
of work involved will not be trivial.
The 6.10.1 release candidate should appear on the 19th, and I will have a
little time at ICFP to whip the spec file and macros into shape.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=460304
--- Comment #9 from Miles Sabin <miles(a)milessabin.com> 2008-09-04 21:06:10 EDT ---
A couple of dozen "good enough" packages would be preferable to zero perfect
ones.
I was under the impression that Yaakov's macros had already been approved.
Bryan also supports them, so do I, so can we just move on now please ...
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=460304
--- Comment #8 from Jens Petersen <petersen(a)redhat.com> 2008-09-04 20:31:13 EDT ---
(In reply to comment #6)
> I'd like to echo Bryan's comment that we should stop haggling and get on with this.
We're not haggling - just trying to come up with a same set of macros that is
actually useful. I think mine are a good improvement on Yaakov's original
proposal and would like to see them or something close to them adopted.
> Rather than dragging this on interminably I think it would be vastly
> preferable to get a few packages built and worry about minor tweaks later.
I disagree: I would rather get a decent of macros in place now than having to
update lots of packages later to take in modifications.
As a person who actually owns some haskell packages in fedora and who started
Haskell packaging for Fedora and the Haskell SIG I hope my suggestions at least
carry a little weight...
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=460304
--- Comment #7 from Jens Petersen <petersen(a)redhat.com> 2008-09-04 20:24:57 EDT ---
(In reply to comment #3)
> These macros present a few problems. They only work for our default compiler,
Can you explain? As far as I can see they should be useful for any Haskell
implementation that support Cabal. They look completely portable to be, as
cabal indeed should be.
> and furthermore, when a user changes the default compiler, could introduce some
> weird breakage in mock when he/she forgets that it uses two different
> compilers.
details?
As others suggested I would like to see these macros get included in rpm
eventually.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=460304
Miles Sabin <miles(a)milessabin.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |miles(a)milessabin.com
--- Comment #6 from Miles Sabin <miles(a)milessabin.com> 2008-09-04 20:01:57 EDT ---
I'd like to echo Bryan's comment that we should stop haggling and get on with
this. Rather than dragging this on interminably I think it would be vastly
preferable to get a few packages built and worry about minor tweaks later.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=460304
--- Comment #5 from Yaakov Nemoy <loupgaroublond(a)gmail.com> 2008-09-04 18:37:22 EDT ---
In that case, we'll need to make a few modifications.
1) the macros should be prefixed with ghc, not cabal or haskell
2) library packages should be prefixed with ghc-, not haskell-
The reasoning is that if someone asks for nhc support, i would rather just have
them do their own nhc packages in a similar manner. It seems the easiest for
now, rather than having to rename haskell-* packages to ghc-* later.
Also, I would like to ask that you backport the macros to everything, because
they are definitely needed in order to build packages. Otherwise, there is no
way we can build stuff on Koji boxes running on Fedora 9 or other versions.
To put this in perspective, the current workflow is to clean out mock, then
copyin the macros. This is not doable with Koji. It's a pain in the you know
what for most users.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=460304
--- Comment #4 from Bryan O'Sullivan <bos(a)serpentine.com> 2008-09-04 15:47:37 EDT ---
I'd really rather we didn't spend much more time haggling over the macros.
Both Jens's and Yaakov's macros are good enough.
For the foreseeable future, we should not care about supporting multiple
compilers, because everybody uses GHC. If some crowd of users comes along who
desperately wants hugs support, I would prefer that we consider their needs
then, rather than adding further delay and contention now.
Unless there's a strong reason not to, I will commit Yaakov's existing macros
file in a day or two. I intend to do this only for ghc 6.8.3 in rawhide,
unless someone thinks we should backport 6.8.3 to F9.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=460304
--- Comment #3 from Yaakov Nemoy <loupgaroublond(a)gmail.com> 2008-09-04 13:38:03 EDT ---
These macros present a few problems. They only work for our default compiler,
and furthermore, when a user changes the default compiler, could introduce some
weird breakage in mock when he/she forgets that it uses two different
compilers.
There has been some demand for macros that work cross platform and build
multiple packages for multiple compilers. I'm going to have a look at a better
way to do this.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.