Bug 425882 - Review Request: ghc-zlib - zlib bindings for ghc
Review Request: ghc-zlib - zlib bindings for ghc
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Extras Quality Assurance
:
: 451149 (view as bug list)
Depends On:
Blocks: 471003
  Show dependency treegraph
 
Reported: 2007-12-17 00:41 EST by Yaakov Nemoy
Modified: 2013-11-13 07:55 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-27 20:53:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
tibbs: fedora‑review+
limburgher: fedora‑cvs+


Attachments (Terms of Use)
ghc-zlib.spec (2.50 KB, text/plain)
2008-10-14 23:43 EDT, Bryan O'Sullivan
no flags Details
ghc-zlib.spec-1.patch (2.86 KB, patch)
2008-10-23 03:54 EDT, Jens Petersen
no flags Details | Diff
ghc-zlib.spec-2.patch (2.55 KB, patch)
2008-11-24 22:37 EST, Jens Petersen
no flags Details | Diff

  None (edit)
Description Yaakov Nemoy 2007-12-17 00:41:32 EST
Spec URL: http://fedorapeople.org/~ynemoy/ghc681-zlib.spec
SRPM URL: http://fedorapeople.org/~ynemoy/ghc681-zlib-0.4.0.1-1.fc8.src.rpm
Description: zlib bindings for ghc 6.8.1

So admittedly this spec file worked better 5 minutes before i copied it than now, but This kinda sorta shows the direction I want to take with haskell packages.

I am actually looking to enter in a bunch of Haskell packages into Fedora, but I want to figure out what is a good way of doing it in a general manner.  Haskell has a large library of packages with package metadata, using a system called 'cabal' and hosting them in a central repository called 'hackagedb'.  It is similar to CPAN or the Python Cheese Shop.  There is also a package called cabal-rpm, that I would like to fix up, so that it can generate many packages that are also Fedora quality.

There are a bunch of issues that need addressing.  The biggest one is the naming scheme.  Let's say a package has the name 'zlib' and it has two executables 'zlib' and 'zlib-setup'.  It also has a library that in haskell is known as 'Zlib', but in the filesystem is saved as 'zlib'.  It would require at bare minimum the following packages in Fedora:

zlib.rpm --the executable
ghc{ver}-zlib  --the library
ghc{ver}-zlib-prof --the profiling extras

there might also be:
zlib-doc --documentation for the binary only
haskell-doc --documentation for the library's api, that is generic to any haskell compiler
ghc{ver}-zlib-doc --documentation that is related to a specific compiler

Ideally, I would like there to be a single spec for a library/program in Fedora for each compiler.  cabal-rpm requires that the compiler be specified when generating the spec file, so I would like to parallel this sentiment.  The spec file would generate at least a library package for each version of that compiler  available in Fedora, where necessary.  It would also create at least a binary compiled with the newest version of that compiler available, and perhaps a binary for other versions as well.

In short, this is why the naming is messed up currently, as I'm not sure what is ultimately the best way to go about this.
Comment 1 Kevin Fenzi 2007-12-21 18:22:51 EST
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?
Comment 2 Yaakov Nemoy 2007-12-21 20:46:20 EST
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.
Comment 3 Bryan O'Sullivan 2007-12-21 22:16:41 EST
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.
Comment 4 Yaakov Nemoy 2007-12-21 22:20:44 EST
I was hoping to do it by example.  I'm using a program that generates these spec
files.
Comment 5 Jason Tibbitts 2007-12-21 22:52:19 EST
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.
Comment 6 Jens Petersen 2008-02-12 22:10:52 EST
Base package name should be ghc-zlib.
Comment 7 Yaakov Nemoy 2008-02-17 18:36:16 EST
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.
Comment 8 Jason Tibbitts 2008-06-17 11:11:14 EDT
*** Bug 451149 has been marked as a duplicate of this bug. ***
Comment 9 Jens Petersen 2008-09-22 21:19:48 EDT
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?
Comment 10 Bryan O'Sullivan 2008-10-14 23:43:19 EDT
Created attachment 320383 [details]
ghc-zlib.spec

This is a rework of the spec file to correspond to the current packaging guidelines.
Comment 11 Bryan O'Sullivan 2008-10-14 23:53:49 EDT
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.
Comment 12 Jason Tibbitts 2008-10-15 20:49:30 EDT
How about rawhide's ghc?  Did the extra macro bits make it in yet?
Comment 13 Bryan O'Sullivan 2008-10-16 20:36:02 EDT
Yes, they're in rawhide.
Comment 14 Jason Tibbitts 2008-10-21 00:16:05 EDT
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.
Comment 15 Bryan O'Sullivan 2008-10-21 00:31:04 EDT
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.
Comment 16 Yaakov Nemoy 2008-10-22 01:23:19 EDT
Sorry, school's kicking my butt again. :/
Comment 17 Jason Tibbitts 2008-10-22 11:24:44 EDT
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.
Comment 18 Bryan O'Sullivan 2008-10-22 11:36:55 EDT
Jason, you are of course right.  Sorry for my oversight.  I hope it didn't waste too much of your time.
Comment 19 Jason Tibbitts 2008-10-22 12:49:41 EDT
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.
Comment 20 Jason Tibbitts 2008-10-22 15:37:12 EDT
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.
Comment 21 Jens Petersen 2008-10-22 23:07:00 EDT
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).
Comment 22 Jason Tibbitts 2008-10-22 23:21:29 EDT
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.
Comment 23 Jens Petersen 2008-10-23 03:51:02 EDT
(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. :)
Comment 24 Jens Petersen 2008-10-23 03:54:43 EDT
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
Comment 25 Jason Tibbitts 2008-10-27 11:07:45 EDT
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.
Comment 26 Bryan O'Sullivan 2008-10-27 18:27:01 EDT
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.
Comment 27 Jens Petersen 2008-10-27 20:46:39 EDT
(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.
Comment 28 Bryan O'Sullivan 2008-11-01 16:56:26 EDT
Jason, is there any more information you need from us before you can proceed?
Comment 29 Jens Petersen 2008-11-02 22:16:43 EST
An updated package would be good I guess... :)
Comment 30 Jason Tibbitts 2008-11-03 11:19:28 EST
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.
Comment 31 Bryan O'Sullivan 2008-11-11 10:44:46 EST
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
Comment 32 Jens Petersen 2008-11-11 19:06:23 EST
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.
Comment 33 Bryan O'Sullivan 2008-11-11 19:08:53 EST
I'm easy. I'll be pushing a nearly-zero-day update of ghc 6.10.1 for f10 if I can.
Comment 34 Jens Petersen 2008-11-12 02:48:37 EST
(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.)
Comment 35 Jason Tibbitts 2008-11-13 14:22:12 EST
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.
Comment 36 Jens Petersen 2008-11-13 19:50:15 EST
(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.)
Comment 37 Jason Tibbitts 2008-11-14 15:18:04 EST
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.
Comment 38 Jason Tibbitts 2008-11-15 11:21:36 EST
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.
Comment 39 Jens Petersen 2008-11-16 23:25:21 EST
Sounds good Jason: BTW I already added the -devel Provides to PackagingDrafts Haskell templates last week.
Comment 41 Jens Petersen 2008-11-24 22:20:29 EST
(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/
Comment 42 Jens Petersen 2008-11-24 22:37:56 EST
Created attachment 324561 [details]
ghc-zlib.spec-2.patch

Update to ghc-6.10.1 and latest draft revised guidelines.
Comment 43 Jens Petersen 2008-11-24 22:41:34 EST
Built in koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=949251 with ghc-6.10.1-4.fc11.
Comment 44 Jason Tibbitts 2008-11-24 23:37:01 EST
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.
Comment 45 Jens Petersen 2008-11-25 01:27:25 EST
(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. :)
Comment 46 Jens Petersen 2008-11-26 01:56:58 EST
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
Comment 47 Dennis Gilmore 2008-11-26 21:42:27 EST
CVS Done
Comment 48 Jens Petersen 2008-11-27 20:53:28 EST
Thanks.  ghc-zlib-0.5.0.0-2.fc11 has been built.
Comment 49 Jens Petersen 2010-09-29 01:43:43 EDT
Package Change Request
======================
Package Name: ghc-zlib
New Branches: el6
Owners: petersen
InitialCC: haskell-sig
Comment 50 Kevin Fenzi 2010-09-29 14:35:38 EDT
Git done (by process-git-requests).
Comment 51 Jens Petersen 2013-11-12 22:36:33 EST
Package Change Request
======================
Package Name: ghc-zlib
New Branches: el5
Owners: petersen
InitialCC: haskell-sig
Comment 52 Jon Ciesla 2013-11-13 07:55:41 EST
Git done (by process-git-requests).

Note You need to log in before you can comment on or make changes to this bug.