Sorry for the slow response. I was away last week.
I've revised the guidelines once again to cover the issues
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
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
** 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.
Anyways, I present the guidelines once more for review. I will try
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.