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