Hi Lists,
I've revised the guidelines once again to cover the issues brought up when I brought them before the packaging committee. As follows is a list of the issues I've heard, and how they are fixed.
* %buildsubdir is not a common way of doing things ** we need this macro in the install phase to get at the working dir we used to compile the package. This was only needed by the rather scary looking file seeking code, so I put it into a macro that is called by another macro, and hid it from public view. The user should not need this in the spec file anymore.
* this looks scary, use macros ** done, the guidelines include them
* how do runtime requirements work, vis a vis build time, etc... ** GHC apparently uses static linking for haskell libraries and dynamic for C libraries. *** This is quite similar to OCaml ** all the dynamic links to C libraries can be automagically detected by RPM's wonderful automagic. ** the -devel packages still need to be put in by hand in the BuildRequires ** most packages only need their dependency libraries at build time. ** Some packages, notably xmonad, do code generation and require the dependencies at run time. *** the packager is responsible for tracking this bit
* this file detection stuff is scary ** I've put it into a series of macros and documented it
* this register stuff looks kinky ** for starters, it's needed so the compiler knows where to look for certain packages ** it's been converted to a bunch of macros
I also think that if we can make this any more simple, then the only thing that cabal-rpm really really needs to do is detect if a package is a library, binary, or both, and then fill in some of the dependencies automatically, whcih it's not clever enough yet to do properly anyways. We may just need to create a few rpm templates, and be done with it.
Anyways, I present the guidelines once more for review. I will try to comandeer the help of the people in the SIG to start putting together a repo of packages using these macros. The deadeline for the F10 feature is coming up soon, and I want to have it in a relatively stable shape, even though we have time to fine tune the details later.
-Yaakov
Hi Yaakov,
Sorry for the slow response. I was away last week.
I've revised the guidelines once again to cover the issues brought up when I brought them before the packaging committee. As follows is a list of the issues I've heard, and how they are fixed.
Thanks for your ongoing work on this. :)
- %buildsubdir is not a common way of doing things
** we need this macro in the install phase to get at the working dir we used to compile the package.
This is not haskell specific and should really not be needed. Let's try to get rid of it.
But how are packages supposed to get these macros? Surely each package is not going to include all of http://ynemoy.fedorapeople.org/haskell/macros.ghc ?
The macros are not really that ghc specific: they should be prefixed cabal not ghc.
IMHO some of it seems to be overkill.
- if %ghc_autotools is necessary, can the -p option be made optional?
I attach an (untested) which cleans up the macro file a bit.
- this file detection stuff is scary
** I've put it into a series of macros and documented it
Ok, that might be useful. :)
- this register stuff looks kinky
** for starters, it's needed so the compiler knows where to look for certain packages ** it's been converted to a bunch of macros
Less worried about that than I used to be. Again the macros don't really buy much.
I don't quite understand %ghc_preinst_script and %ghc_postun_script: why do we need them?
I also think that if we can make this any more simple, then the only thing that cabal-rpm really really needs to do is detect if a package is a library, binary, or both, and then fill in some of the dependencies automatically, which it's not clever enough yet to do properly anyways. We may just need to create a few rpm templates, and be done with it.
Yes, maybe.
Anyways, I present the guidelines once more for review. I will try to comandeer the help of the people in the SIG to start putting together a repo of packages using these macros. The deadline for the F10 feature is coming up soon, and I want to have it in a relatively stable shape, even though we have time to fine tune the details later.
We really need to get some packages in the queue reviewed first to check the sanity of the draft. And IMHO better to use KISS than too much overengineering. We can add more macros if necessary after more experience at a later revision.
Jens
On Fri, Aug 22, 2008 at 3:53 AM, Jens Petersen petersen@redhat.com wrote:
Hi Yaakov,
Sorry for the slow response. I was away last week.
Ditto.
- %buildsubdir is not a common way of doing things
** we need this macro in the install phase to get at the working dir we used to compile the package.
This is not haskell specific and should really not be needed. Let's try to get rid of it.
It's needed for the macros that do file detection later on. Once we cd into the buildroot, we need a way of accessing the old dir we used to compile the package. Therefore, I've put it in a macro, and both sets of macros are mandatory. If you have a better solution, please fix it.
But how are packages supposed to get these macros? Surely each package is not going to include all of http://ynemoy.fedorapeople.org/haskell/macros.ghc ?
That file is going to be packaged with ghc itself. I've submitted the following bug.
https://bugzilla.redhat.com/show_bug.cgi?id=460304
The macros are not really that ghc specific: they should be prefixed cabal not ghc.
Technically no, but I want to differentiate between what the theoretical command might be for foo haskell compiler, and what nuances there might be between compilers.
IMHO some of it seems to be overkill.
How so? For the most part, i'm converting the work that Bryan has done into macros, and polished it up. Every step that's there is stuff that Bryan has decided is necessary.
- if %ghc_autotools is necessary, can the -p option be made optional?
What should the default be?
I attach an (untested) which cleans up the macro file a bit.
I've attached that to the bug report to add them to GHC.
- this file detection stuff is scary
** I've put it into a series of macros and documented it
Ok, that might be useful. :)
- this register stuff looks kinky
** for starters, it's needed so the compiler knows where to look for certain packages ** it's been converted to a bunch of macros
Less worried about that than I used to be. Again the macros don't really buy much.
I don't quite understand %ghc_preinst_script and %ghc_postun_script: why do we need them?
Bryan answered this.
I also think that if we can make this any more simple, then the only thing that cabal-rpm really really needs to do is detect if a package is a library, binary, or both, and then fill in some of the dependencies automatically, which it's not clever enough yet to do properly anyways. We may just need to create a few rpm templates, and be done with it.
Yes, maybe.
Anyways, I present the guidelines once more for review. I will try to comandeer the help of the people in the SIG to start putting together a repo of packages using these macros. The deadline for the F10 feature is coming up soon, and I want to have it in a relatively stable shape, even though we have time to fine tune the details later.
We really need to get some packages in the queue reviewed first to check the sanity of the draft. And IMHO better to use KISS than too much overengineering. We can add more macros if necessary after more experience at a later revision.
I have a couple of volunteers. Gotta follow up on this.
-Yaakov
"YN" == Yaakov Nemoy loupgaroublond@gmail.com writes:
YN> I have a couple of volunteers. Gotta follow up on this.
Well, perhaps you're unaware, but the draft has passed FPC and a few hours ago passed FESCo and will become official next week unless significant objections are raised. Of course, we need those macros in GHC before things will actually build, and I don't think all of the submitted packages actually conform to the approved draft so there may be a bit of work before they can pass a review.
- J<
Jason L Tibbitts III さんは書きました:
"YN" == Yaakov Nemoy loupgaroublond@gmail.com writes:
YN> I have a couple of volunteers. Gotta follow up on this.
Well, perhaps you're unaware, but the draft has passed FPC and a few hours ago passed FESCo and will become official next week unless significant objections are raised.
Sigh, how is that possible when we are still discussing the details?
Of course, we need those macros in GHC before things will actually build, and I don't think all of the submitted packages actually conform to the approved draft so there may be a bit of work before they can pass a review.
I really wanted to have the horse in front of the cart...
Jens
"JP" == Jens Petersen petersen@redhat.com writes:
JP> Sigh, how is that possible when we are still discussing the JP> details?
Because the draft was submitted to us as complete, and we voted on it. If someone didn't want us to vote on it, it would have been nice if someone had let us know. It's been on the schedule for a long time, and only yesterday were we able to assemble a quorum.
- J<
Hi Jason,
Because the draft was submitted to us as complete, and we voted on it.
I understood that it was submitted as a draft for comments...
If someone didn't want us to vote on it, it would have been nice if someone had let us know.
I thought that was what this discussion was about:
https://www.redhat.com/archives/fedora-packaging/2008-August/thread.html#000...
Thanks for the headsup anyway. :)
Jens
On Wed, Aug 27, 2008 at 8:26 PM, Jens Petersen petersen@redhat.com wrote:
Hi Jason,
Because the draft was submitted to us as complete, and we voted on it.
I understood that it was submitted as a draft for comments...
Long ago, i got tired of submitting drafts for comments to have to wait. I took spot's advice and just submitted them for review and comment simultaneously. The principle idea was that I put a deadline on the commenting period, and if there were no comments by a certain time, then it would go straight to review. This way, two groups of people got a chance to look at the drafts at the same time.
Finally, it went for a review by the Committee, and they made their comments. We also discussed your comments. I addressed their comments, which was the final request for review.
Like I said (accidentally offlist), it's not set in stone either, I'm still listening.
-Yaakov
On Wed, 2008-08-27 at 21:00 -0400, Yaakov Nemoy wrote:
Long ago, i got tired of submitting drafts for comments to have to wait. I took spot's advice and just submitted them for review and comment simultaneously.
We can always change and improve guidelines. It doesn't have to be perfect to pass, the FPC will make suggestions and improvements (see the Font drafts that we revised) on most drafts, and only completely reject items that we disagree with entirely.
In scenarios like "programming language $FOO", the FPC is not going to be the experts, we're going to generally trust the people who are. What we're looking for is that the guideline draft is:
A) As simple as possible B) As consistent with the rest of Fedora as possible C) As well documented as possible D) Accompanied with thorough example specs E) Something that enables any Fedora contributor to do a review without being an expert in that language
~spot
On Wed, Aug 27, 2008 at 6:58 PM, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"YN" == Yaakov Nemoy loupgaroublond@gmail.com writes:
YN> I have a couple of volunteers. Gotta follow up on this.
Well, perhaps you're unaware, but the draft has passed FPC and a few hours ago passed FESCo and will become official next week unless significant objections are raised. Of course, we need those macros in GHC before things will actually build, and I don't think all of the submitted packages actually conform to the approved draft so there may be a bit of work before they can pass a review.
I'm really happy to hear this. I've already opened a bug for this. There are workarounds, but none of them are an optimal situation for the likes of Koji.
-Yaakov
(Late followup since I spent most of yesterday working on a cabal-rpm patch.)
Yaakov Nemoy さんは書きました:
- %buildsubdir is not a common way of doing things
** we need this macro in the install phase to get at the working dir we used to compile the package.
This is not haskell specific and should really not be needed. Let's try to get rid of it.
It's needed for the macros that do file detection later on. Once we cd into the buildroot, we need a way of accessing the old dir we used to compile the package. Therefore, I've put it in a macro, and both sets of macros are mandatory. If you have a better solution, please fix it.
No it is not needed: you could use ${RPM_BUILD_DIR} for that if necessary (however see also the end of this mail).
But how are packages supposed to get these macros? Surely each package is not going to include all of http://ynemoy.fedorapeople.org/haskell/macros.ghc ?
That file is going to be packaged with ghc itself. I've submitted the following bug. https://bugzilla.redhat.com/show_bug.cgi?id=460304
Do any other packages (languages) in Fedora provide rpm macros? One of the things I always liked about fedora is that our spec files are self-contained unlike some other distros. Are we moving anyway from that?
Also housing the macros in ghc means that if we need to change them then ghc needs to be rebuild which is a bit expensive - though hopefully that would be not necessary too often.
The macros are not really that ghc specific: they should be prefixed cabal not ghc.
Technically no, but I want to differentiate between what the theoretical command might be for foo haskell compiler, and what nuances there might be between compilers.
I would prefer just a few macros suitable for cabal that would work across ghc, hugs, etc, than something very specific to ghc.
IMHO some of it seems to be overkill.
How so? For the most part, i'm converting the work that Bryan has done into macros, and polished it up. Every step that's there is stuff that Bryan has decided is necessary.
I created some patches to cleanup cabal-rpm's output. I wish you had made clear earlier that that was where all this was coming from... if I had known that I could have cleaned it up much earlier...
As I noted yesterday: I finally tried cabal-rpm and finally realised where all those macros are coming from. So sorry to Yaakov: it seems most of my quibbles have actually been with cabal-rpm! ;)
I think I may submit a cabal-rpm package to fedora so that it can be included.
IMHO a couple of self-contained spec templates are still quite sufficient for now and that is the way I am inclined to go. Packaging cabal packages is really not that hard, and to me hiding small incantation in obscure macros really does not buy use much at all. As long as packages follow the templates reviews should be just as straightforward.
- if %ghc_autotools is necessary, can the -p option be made optional?
What should the default be?
Profiling by default? I don't use profile much myself... what do others think?
I attach an (untested) which cleans up the macro file a bit.
I've attached that to the bug report to add them to GHC.
Thanks. There are still more changes that need to be made though.
- this file detection stuff is scary
** I've put it into a series of macros and documented it
Ok, that might be useful. :)
Has anyone other than me tested them though? The filelist macros in the ghc-X11 review do not work for me, and they seem to be the same as in the current macros...
I just submitted a patch for it in ghc-X11 review https://bugzilla.redhat.com/show_bug.cgi?id=426751#c14 now. (Also in my cabal-rpm patches.)
Jens
On Fri, Aug 29, 2008 at 02:28:41PM +1000, Jens Petersen wrote:
Do any other packages (languages) in Fedora provide rpm macros? One of the things I always liked about fedora is that our spec files are self-contained unlike some other distros. Are we moving anyway from that?
The base ocaml package contains a couple of scripts which are then used by all the OCaml packages. https://fedoraproject.org/wiki/Packaging/OCaml#Requires_and_provides
The aim is to get these two scripts into upstream RPM eventually, where "eventually" is defined as when we get an upstream OCaml bug that affects these scripts fixed.
Rich.
self-contained unlike some other distros. Are we moving anyway from that?
Also housing the macros in ghc means that if we need to change them then ghc needs to be rebuild which is a bit expensive - though hopefully that would be not necessary too often.
This thread is getting even more confusing. :-( I think what Yaakov mentioned was that these macros would be used only for compiling Hackage/Cabal packages (and the like) and not for building the GHC compiler itself. Right Yaakov?
For now I have decided to use a modified version of Yaakov's original macros.ghc file, and build a test package with it and submit it. Will keep everyone updated in the following mails.
-Rajesh
On 2008-08-28-Thu 09:28:41 pm Jens Petersen wrote:
(Late followup since I spent most of yesterday working on a cabal-rpm patch.)
Yaakov Nemoy さんは書きました:
- %buildsubdir is not a common way of doing things
** we need this macro in the install phase to get at the working dir we used to compile the package.
This is not haskell specific and should really not be needed. Let's try to get rid of it.
It's needed for the macros that do file detection later on. Once we cd into the buildroot, we need a way of accessing the old dir we used to compile the package. Therefore, I've put it in a macro, and both sets of macros are mandatory. If you have a better solution, please fix it.
No it is not needed: you could use ${RPM_BUILD_DIR} for that if necessary (however see also the end of this mail).
But how are packages supposed to get these macros? Surely each package is not going to include all of http://ynemoy.fedorapeople.org/haskell/macros.ghc ?
That file is going to be packaged with ghc itself. I've submitted the following bug. https://bugzilla.redhat.com/show_bug.cgi?id=460304
Do any other packages (languages) in Fedora provide rpm macros? One of the things I always liked about fedora is that our spec files are self-contained unlike some other distros. Are we moving anyway from that?
Also housing the macros in ghc means that if we need to change them then ghc needs to be rebuild which is a bit expensive - though hopefully that would be not necessary too often.
The macros are not really that ghc specific: they should be prefixed cabal not ghc.
Technically no, but I want to differentiate between what the theoretical command might be for foo haskell compiler, and what nuances there might be between compilers.
I would prefer just a few macros suitable for cabal that would work across ghc, hugs, etc, than something very specific to ghc.
IMHO some of it seems to be overkill.
How so? For the most part, i'm converting the work that Bryan has done into macros, and polished it up. Every step that's there is stuff that Bryan has decided is necessary.
I created some patches to cleanup cabal-rpm's output. I wish you had made clear earlier that that was where all this was coming from... if I had known that I could have cleaned it up much earlier...
As I noted yesterday: I finally tried cabal-rpm and finally realised where all those macros are coming from. So sorry to Yaakov: it seems most of my quibbles have actually been with cabal-rpm! ;)
I think I may submit a cabal-rpm package to fedora so that it can be included.
IMHO a couple of self-contained spec templates are still quite sufficient for now and that is the way I am inclined to go. Packaging cabal packages is really not that hard, and to me hiding small incantation in obscure macros really does not buy use much at all. As long as packages follow the templates reviews should be just as straightforward.
- if %ghc_autotools is necessary, can the -p option be made optional?
What should the default be?
Profiling by default? I don't use profile much myself... what do others think?
I attach an (untested) which cleans up the macro file a bit.
I've attached that to the bug report to add them to GHC.
Thanks. There are still more changes that need to be made though.
- this file detection stuff is scary
** I've put it into a series of macros and documented it
Ok, that might be useful. :)
Has anyone other than me tested them though? The filelist macros in the ghc-X11 review do not work for me, and they seem to be the same as in the current macros...
I just submitted a patch for it in ghc-X11 review https://bugzilla.redhat.com/show_bug.cgi?id=426751#c14 now. (Also in my cabal-rpm patches.)
Jens
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
Le vendredi 29 août 2008 à 14:28 +1000, Jens Petersen a écrit :
But how are packages supposed to get these macros? Surely each package is not going to include all of http://ynemoy.fedorapeople.org/haskell/macros.ghc ?
That file is going to be packaged with ghc itself. I've submitted the following bug. https://bugzilla.redhat.com/show_bug.cgi?id=460304
Do any other packages (languages) in Fedora provide rpm macros?
Java packages have been build for years on multiple distributions and distribution releases using the jpackage-utils rpm which is basically a set of rpm macros, default directories and utility scripts.
The only problem it caused is when a distribution added a distro-specific script and didn't push it bach upstream.
Before this package was introduced maintaining consistency within a large set of packages that all defined manually the same paths and scripts (in a slightly different way) was hell.
It also makes it way easier to rebuild on distro releases with different rpm versions. If you merge your macros in rpm itself (not that it was possible until the rpm project was resurected) any macro change or addition will hit the huge inertia of rpm itself.
packaging@lists.fedoraproject.org
-
Jason L Tibbitts III -
Jens-Ulrik Petersen -
Nicolas Mailhot -
Rajesh Krishnan -
Richard W.M. Jones -
Tom Callaway -
Yaakov Nemoy