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
On Wed, Aug 13, 2008 at 8:01 AM, Yaakov Nemoy loupgaroublond@gmail.com wrote:
I've revised the guidelines once again to cover the issues brought up when I brought them before the packaging committee.
Thanks, Yaakov.
- 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
Right. At some point in the next year or so, GHC should be able to generate shared libraries, so the AutoReqProv mechanism will then work.
- this file detection stuff is scary
** I've put it into a series of macros and documented it
The reason that the file detection code is complicated is that GHC emits a number of .o and .a files. These change depending on the compilation options used. The files follow a consistent naming convention, so it is far easier and more reliable to gather them up using a find script than to enumerate all of the possibilities by hand.
I'm pleased with the current state of the guidelines. Thanks for working on this!
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
Jens Petersen wrote:
I don't quite understand %ghc_preinst_script and %ghc_postun_script: why do we need them?
Here's the rationale for those bits:
http://www.serpentine.com/blog/2007/02/20/haskell-cabal-now-with-extra-crunc...
Quoting:
Let me point out a wrinkle I encountered when registering RPM-installed packages with GHC. When upgrading an RPM file that contains the same Cabal name+version of a package as the previously installed version (say with only an RPM release being different), the %pre, %post, %preun, and %postun scripts will all be asking GHC to register/unregister what it thinks are the same library. As a result, when the %preun script is called, which occurs *after* the new package is installed but before the old package is removed, its unregister script will actually unregister the newly installed library, leaving the new library unregistered with GHC.
To test for the problem, take the existing spec file for an already-installed package, bump its RPM release, rebuild the RPMs, and then try to upgrade to the new version. After the upgrade, GHC will no longer know about the package.
To avoid this problem, I’ve worked out the following spec-script dance...
Cheers, Tom
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
(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
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
haskell-devel@lists.fedoraproject.org
-
Bryan O'Sullivan -
Jens-Ulrik Petersen -
Rajesh Krishnan -
Tom Moertel -
Yaakov Nemoy