Bug 425882

Before reviewing this, perhaps it would be best to have a discussion on the
fedora-packaging list and try and hammer out some good ghc guidelines?

Can you try posting there and see if they can come up with some sort of
guideline given the issues you have run into?

I had a talk with Bryan O Sullivan about some of these issues.  He's only
planning on supporting the latest GHC right now, so I have a better Idea what to
do now.  I"m going to refactor this spec file, and come up with something better.

Frankly, it probably still makes sense for us to write up some formal packaging
guidelines for Haskell before we proceed.  This is what the OCaml SIG has
already done, and they face many of the same issues.

I was hoping to do it by example.  I'm using a program that generates these spec
files.

I can only encourage folks who understand Haskell to try to write up some basic
guidelines.  The Packaging Committee will be happy to help with this, but I'm
not sure that any of us understand Haskell well enough to actually formulate
guidelines on our own.

Base package name should be ghc-zlib.

With much further ado, here is an updated version of the package.  It should be
closer to what the final spec is going to look like.

SRPM: http://ynemoy.fedorapeople.org/review/ghc-zlib-0.4.0.2-2.fc8.src.rpm
spec: http://ynemoy.fedorapeople.org/review/ghc-zlib.spec

Reviewing it will probably have to work like this.  This file is going to
closely match the Haskell Packaging Guidelines draft. (in fact so closely, that
the actual text of this spec file will be linked to it, as an example.)  This
package needs to be checked against the rest of the review processes and rules.
 If there are any conflicts between this and the review rules, we'll edit the
draft to match something more correct.  The same applies to other issues or
problems.

*** Bug 451149 has been marked as a duplicate of this bug. ***

It would nice to have this package so we can also get cabal-install into Fedora.

Can you do an update of the submitted package?

Created attachment 320383 [details]
ghc-zlib.spec

This is a rework of the spec file to correspond to the current packaging guidelines.

BTW, the ghc in F-9 can't build this yet, because it hasn't been brought up to date w.r.t. the current guidelines. We're working to fix this.

How about rawhide's ghc?  Did the extra macro bits make it in yet?

Yes, they're in rawhide.

Is there an updated srpm that should be reviewed?  I'll be happy to look at this package but I'm not sure if Yaakov is still working on this.

Thanks, Jason.  Yaakov is busy with other stuff at the moment and likely to remain so for a while, so here are the latest spec and SRPM files:

http://bos.fedorapeople.org/ghc-zlib-0.4.0.4-1.fc10.src.rpm
http://bos.fedorapeople.org/ghc-zlib.spec

Remember that these need a fresh rawhide ghc (I have ghc-6.10.0.20081007-6.fc11.x86_64) to work.

The rpmlint warnings for the binary RPMs are expected and normal.

Sorry, school's kicking my butt again. :/

Unfortunately I think that instead of "rawhide" you really mean "from the F-11 branch" because the latest package tagged into rawhide is ghc-6.8.3-8.fc10.  I'll have to cook up a mock config to suck in dist-f11.

Jason, you are of course right.  Sorry for my oversight.  I hope it didn't waste too much of your time.

Well, actually I'm about 1.5 hours into downloading the ghc packages from static-repos.  Only about 30MB (out of 77MB) to go!  Caching should of course make this reasonable in the future, but it still takes 20 minutes just to pull fresh repodata.

Finally.

This is the first one of these I've seen being done, so I'll have a few probably obvious questions.

First off, why the hsc_name macro?  Or rather, why go to the trouble of defining it to "ghc" only to use "ghc" explicitly later?  Wouldn't it be simpler just to not use the macro at all?

If you build a package against ghc-zlib, will it be required at runtime?  I guess what's confusing me is all the talk of static linking, and yet the .a file is packaged, which implies that this is really some sort of -devel package needed at compile time.  Is there no kind of runtime/-devel split of these packages?

There's no reason to include the LICENSE file twice, is there?

Otherwise the %ghc_* macros hide all of the complexity nicely.  I'm not sure I'd know how to find a test suite if one were included, so I can't really check that.  With some good answers to the above questions I don't see any reason this wouldn't pass review.

I just pushed ghc-6.8.3-9.fc10 to koji so this package review should be able to proceed from rawhide soon.  Note that I added a new macro pkg_docdir so that should take care of tibbs' comment on hsc_name (I have been working to get rid of the latter macro).

Erm, did you mean to to set this back to NEW and assign it back to nobody?  Actually, I didn't even think you could set a ticket back to NEW after its been assigned; at least, the web interface won't let you.  I wonder how that happened.

(In reply to comment #21)
> I just pushed ghc-6.8.3-9.fc10 to koji

Please ghc-6.8.3-10.fc10 with a fixed %cabal_configure for ghc-6.8.3.

(In reply to comment #22)
> Erm, did you mean to to set this back to NEW and assign it back to nobody? 

Oops, sorry - no I didn't - I guess I already had the bug open in my browser.

Jason, I didn't mean to steal the review from you, but I was planning on taking it since I am familiar with Haskell packaging and since no package review has yet been through the new haskell guidelines I might be better placed to do this one?  But if you want to take it I won't stand in your way. :)

Created attachment 321249 [details]
ghc-zlib.spec-1.patch

A bit of cleanup/simplification and make it build with ghc-6.8.3 in current rawhide

Honestly as an FPC member I'm quite interested in actually seeing how the guidelines work for someone who is not familiar with Haskell.  Besides, at this point it seems as if you are submitting the package, which would mean that it is quite inappropriate for you to be reviewing it as well.

Before progressing, though, the remaining questions in comment #20 need answers.

Re comment #20:

> If you build a package against ghc-zlib, will it be required at runtime?

No.  These Haskell packages are essentially devel packages.

> There's no reason to include the LICENSE file twice, is there?

No.  If that's happening, it's a mistake.

(In reply to comment #20)
> Is there no kind of runtime/-devel split of these packages?

Current releases of ghc do not support shared libraries on Linux (though this may change in come releases).

> I'm not sure I'd know how to find a test suite if one were included, so I can't really check that.

I don't think there is one included in the package.

Jason, is there any more information you need from us before you can proceed?

An updated package would be good I guess... :)

Yes, I need an updated package to review.  I have been away for a few days but I don't think I missed any notice of one being made available.

OK, here are the links to the new packages:

http://bos.fedorapeople.org/ghc-zlib-0.5.0.0-1.fc9.src.rpm
http://bos.fedorapeople.org/ghc-zlib.spec

Thanks, Bryan.  Perhaps the review should target f11 now since we have ghc-6.10.1 in dist-f11.
But that is up to Jason really.

I'm easy. I'll be pushing a nearly-zero-day update of ghc 6.10.1 for f10 if I can.

(In reply to comment #33)
> I'm easy.

Basically the package looks pretty good to me now, my only comment is that we need requires for all the install scripts I guess.  Because of not needing haddock09 those would also look easier with dist-f11 in koji

# for ghc-pkg and haddock
Requires(pre): ghc = %{ghc_version}
Requires(preun): ghc = %{ghc_version}
Requires(post): ghc = %{ghc_version}
Requires(postun): ghc = %{ghc_version}

(they need to be versioned for ghc-pkg)

> I'll be pushing a nearly-zero-day update of ghc 6.10.1 for f10 if I can.

(It might be better to wait a little longer I think for ghc-6.10.1 to stabilise and also after seeing how much work it was updating f9 to ghc-6.8.3, but let's see how we go.)

One remaining question: if ghc library packages in the future do grow a runtime component, that will imply not only that this package grows a -devel subpackage but that anything which build against it has to change to having a build dependency on the -devel package.  That could be avoided now in a couple of ways, but I don't know whether the possibility of ghc supporting shared libraries is sufficiently remote that its not worth it.  The simplest way is for this package to provide ghc-zlib-devel and for other packages to BuildRequires: that.  In any case, I'll leave that up to you folks.

You will definitely need some extra dependencies for the scriptlets.  I think there's one that's not listed above in comment 34; you'll need Rerquires(postun): haddock for the %ghc_reindex_haddock script.  I'm not sure what is required for the register.sh and unregister.sh scripts although I suspect the above list should do it.

We definitely need to get the full list of dependencies into the guidelines.  Currently I think the haddock ones are missing.  Or am I confused and is haddock somehow brought in by ghc?

rpmlint output:
  ghc-zlib.x86_64: W: devel-file-in-non-devel-package 
   /usr/lib64/ghc-6.8.3/zlib-0.5.0.0/libHSzlib-0.5.0.0.a
  ghc-zlib.x86_64: E: devel-dependency zlib-devel
  ghc-zlib-prof.x86_64: W: no-documentation
  ghc-zlib-prof.x86_64: W: devel-file-in-non-devel-package 
   /usr/lib64/ghc-6.8.3/zlib-0.5.0.0/libHSzlib-0.5.0.0_p.a
I agree that the above are all acceptable and expected.

* source files match upstream:
   20e067cfbec87ec062ac144875a60e158ea6cf7836aac031ec367fcdd5446891
   zlib-0.5.0.0.tar.gz
* package meets naming and versioning guidelines.
   (library for ghc -> ghc- prefix)
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text included in package.
* BuildRequires are proper.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* rpmlint has acceptable complaints.
X Scriptlet dependencies are mostly missing.
  final provides and requires:

  ghc-zlib-0.5.0.0-1.fc10.x86_64.rpm
   ghc-zlib = 0.5.0.0-1.fc10
   ghc-zlib(x86-64) = 0.5.0.0-1.fc10
  =
   /bin/sh
   ghc = 6.8.3
   haddock09
   zlib-devel

  ghc-zlib-prof-0.5.0.0-1.fc10.x86_64.rpm
   ghc-zlib-prof = 0.5.0.0-1.fc10
   ghc-zlib-prof(x86-64) = 0.5.0.0-1.fc10
  =
   ghc-zlib = 0.5.0.0

* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no generically named files
* scriptlets present.
* code, not content.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.

(In reply to comment #35)
> One remaining question: if ghc library packages in the future do grow a runtime
> component, that will imply not only that this package grows a -devel subpackage
> but that anything which build against it has to change to having a build
> dependency on the -devel package.  That could be avoided now in a couple of
> ways, but I don't know whether the possibility of ghc supporting shared
> libraries is sufficiently remote that its not worth it.  The simplest way is
> for this package to provide ghc-zlib-devel and for other packages to
> BuildRequires: that.  In any case, I'll leave that up to you folks.

That is a very good suggestion and I think we should adopt that, since ghc is moving to support shared libraries.

> We definitely need to get the full list of dependencies into the guidelines. 
> Currently I think the haddock ones are missing.  Or am I confused and is
> haddock somehow brought in by ghc?

ghc-6.10.1 includes a version of haddock now, but ghc-6.8.3 does not.
(Hence my suggestion to do the review against ghc-6.10.1, but it is not yet in rawhide, just dist-f11.)

That is a bit confusing; I didn't realize that haddock was moving into ghc, and unfortunately "rawhide" won't actually be rawhide for some time and while I can do build testing in koji its tough to do any actual install testing unless I work against static-repos.  Unfortunately download speeds from there are so terribly slow that it takes me hours to init a buildroot.  Let me see what I can  come up with.

So if I understand correctly, for ghc-6.10.1 the scriptlet dependencies should just be:

Requires(pre): ghc = %{ghc_version}
Requires(preun): ghc = %{ghc_version}
Requires(post): ghc = %{ghc_version}
Requires(postun): ghc = %{ghc_version}

And the "Requires(post): haddock09" bit can go.

OK, I can verify that the package installs into a fresh dist-f11 buildroot with the dependencies as above and the package tweaked to build against ghc-6.10.1.  So where are we?  Basically, you tell me what you wnat to do.  I guess at this point I'd say to just target ghc-6.10.1, drop "Requires(post): haddock09", add the -devel provide and we're good to go.

Sounds good Jason: BTW I already added the -devel Provides to PackagingDrafts Haskell templates last week.

I mean https://fedoraproject.org/wiki/PackagingDrafts/Haskell/LibraryOnlyTemplate

(In reply to comment #20)
> There's no reason to include the LICENSE file twice, is there?

Yes, probably not, but I think actually the -prof subpackage should not require the main package (just ghc-prof), so it would be possible to install -prof alone.  Does that change anything?


I am adding a little shell script called cabal2spec in ghc-6.10.1-5.fc11 which generates a ghc library spec files for a hackage tarball argument from cabal-lib-template.spec.  It could also generate ghc-zlib.spec with build_doc and build_prof switches.

See http://cvs.fedoraproject.org/viewvc/devel/ghc/

Created attachment 324561 [details]
ghc-zlib.spec-2.patch

Update to ghc-6.10.1 and latest draft revised guidelines.

Built in koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=949251 with ghc-6.10.1-4.fc11.

The opinion from the legal folks is that even if a srpm creates subpackages that are not related in name or dependency chain, it is still only necessary to include the license file in one of them.  It's been discussed, however, and it's also not a blocker if that's really what you want to do.  Honestly I would suggest that any templates or automated tools not have %files lists with duplicated files so that less experienced packagers don't get the impression that it is necessary to duplicate the license file or acceptable in general to have duplicate entries in %files lists.

I believe that with the patch in comment 42, this package is fine, and I'm happy to see this through.

APPROVED

I guess we need another guideline update to handle the changed scriptlets, though.

(In reply to comment #44)
> Honestly I would suggest that any templates or automated tools not have %files lists with
> duplicated files so that less experienced packagers don't get the impression
> that it is necessary to duplicate the license file or acceptable in general to
> have duplicate entries in %files lists.

Right - I will remove it.

> I believe that with the patch in comment 42, this package is fine, and I'm
> happy to see this through.

Thanks for reviewing the first new haskell library package. :-)

> I guess we need another guideline update to handle the changed scriptlets, though.

Yep.  Planning to rework the text, then rfc, and submit to FPC again for review. :)

For completeness here is the final package:
Spec URL: http://petersen.fedorapeople.org/ghc-zlib.spec
SRPM URL: http://petersen.fedorapeople.org/ghc-zlib-0.5.0.0-2.fc10.src.rpm


New Package CVS Request
=======================
Package Name: ghc-zlib
Short Description: Haskell compression and decompression library
Owners: petersen bos
Branches: F-10 F-9
InitialCC: haskell-sig

CVS Done

Thanks.  ghc-zlib-0.5.0.0-2.fc11 has been built.

Package Change Request
======================
Package Name: ghc-zlib
New Branches: el6
Owners: petersen
InitialCC: haskell-sig

Git done (by process-git-requests).

Package Change Request
======================
Package Name: ghc-zlib
New Branches: el5
Owners: petersen
InitialCC: haskell-sig

Git done (by process-git-requests).