Revised Haskell Guidelines 2008.08.13

[Yaakov Nemoy]

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

[Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13

[Jens-Ulrik Petersen]

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

[Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13

[Yaakov Nemoy]

On Fri, Aug 22, 2008 at 3:53 AM, Jens Petersen <petersen(a)redhat.com&gt; 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

[Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13

[Jason L Tibbitts III]

> >>>> "YN" == Yaakov Nemoy
> <loupgaroublond(a)gmail.com&gt; 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<

[Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13

[Jens-Ulrik Petersen]

Jason L Tibbitts III さんは書きました:
> >>>>> "YN" == Yaakov Nemoy
> <loupgaroublond(a)gmail.com&gt; 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

[Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13

[Jason L Tibbitts III]

> >>>> "JP" == Jens Petersen
> <petersen(a)redhat.com&gt; 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<

[Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13

[Jens-Ulrik Petersen]

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#...

Thanks for the headsup anyway. :)

Jens

[Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13

[Yaakov Nemoy]

On Wed, Aug 27, 2008 at 8:26 PM, Jens Petersen <petersen(a)redhat.com&gt; 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

[Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13

[Tom Callaway]

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

[Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13

[Yaakov Nemoy]

On Wed, Aug 27, 2008 at 6:58 PM, Jason L Tibbitts III <tibbs(a)math.uh.edu&gt; wrote:
> >>>>> "YN" == Yaakov Nemoy
> <loupgaroublond(a)gmail.com&gt; 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

[Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13

[Jens-Ulrik Petersen]

(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-haskell-list] Revised Haskell Guidelines 2008.08.13

[Richard W.M. Jones]

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.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 64 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

[Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13

[Rajesh Krishnan]

>  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(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-packaging

[Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13

[Nicolas Mailhot]

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.

-- 
Nicolas Mailhot