[Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13

Jens Petersen petersen at redhat.com
Fri Aug 29 04:28:41 UTC 2008


(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




More information about the Fedora-packaging mailing list