Bug 189197
Summary: | Review Request: gtk2hs - Haskell gtk2 binding (renamed to ghc-gtk2hs) | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jens Petersen <petersen> | ||||
Component: | Package Review | Assignee: | Gérard Milmeister <gemi> | ||||
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Package Reviews List <fedora-package-review> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | gemi, haskell-devel | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
URL: | http://haskell.org/gtk2hs/ | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2006-05-15 05:12:22 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 163779 | ||||||
Attachments: |
|
Description
Jens Petersen
2006-04-18 09:31:52 UTC
* Could you update the package to ghc-6.4.2? * BuildRoot must be: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) * Is the epoch necessary for mozilla version? * I think PreReq should simply be Requires * ghclibdir should probably %{_libdir}/ghc-%{ghc_version} * Can you explain your system of versioning? (In reply to comment #1) > * Could you update the package to ghc-6.4.2? Yep, I updated the package with some changes: http://people.redhat.com/petersen/extras/ghc-gtk2hs.spec http://people.redhat.com/petersen/extras/ghc-gtk2hs-0.9.10-2.src.rpm > * BuildRoot must be: > %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Fixed. > * Is the epoch necessary for mozilla version? Yes. > * I think PreReq should simply be Requires I prefer PreReq for post/preun requirements: it is equivalent to Requires actually, but if you object I can change it. > * ghclibdir should probably %{_libdir}/ghc-%{ghc_version} Well ghc upstream has said that %{_libdir}/ghc-%{ghc_version} should be reserved for ghc itself. For cabalised packages I'm using %{_libdir}/ghc as the library prefix: it would be good if gtk2hs followed this scheme too IMHO. I hear upstream is planning to make the install configuration more flexible, but for now maybe the current location is good enough. > * Can you explain your system of versioning? You mean the package naming scheme? That is a bit of a long story. :) This is the naming scheme I have been using for a while for libraries and ghc in Fedora Haskell <http://haskell.org/fedora/>. Let me try to summarize here. The starting point is the fact that ghc changes ABI with every minor version update (this is the main reason for the ghcXYZ subpackaging of ghc: ie currently there is ghc, ghc642, ghc642-prof); so since ghc is rather a large package to rebuild as a compat- package say it seemed to make more sense to me to allow parallel installs of ghcXYZ's (so you can install ghc641 with ghc642, etc and still be able to compile with your old libraries built for ghc641 say) until you can update them to ghc642. While gtk2hs builds quicker than ghc it is still pretty time-consuming to build, so following the ghc scheme it is subpackaged for ghcXYZ. I decided to make subpackages for each ghc package (gtk, glib, sourceview, etc) since they depend on the corresponding {gtk2,glib2,sourceview}-devel packages and so people can just install what they need: probably ghcXYZ-gtk would be most common. Again this allows parallel installs of libraries (gtk2hs) for parallel installs of ghc. Does that make some sense? I can go into more details if you wish. In the latest naming scheme now I'm just using the ghc-package name to name the subpackages (ghcXYZ-glib rather than ghc642-gtk2hs-glib etc) since that is what the ghc package is actually called so it seems more natural. The ghcXYZ scheme also means that if you have say ghc641-gtk installed with ghc-6.4.1, you can upgrade to ghc-6.4.2 without breaking the deps for ghc641 libs like gtk2hs, and then later update to ghc642-gtk when it is available. Created attachment 128411 [details]
modified spec file
1. I modified the spec file so that I can find my way around more easily. You are free to use it. 2. I think the documentation package should install the documentation in gtk2hs-doc-%{version} or ghc-gtk2hs-doc-%{version}, since all directories in /usr/share/doc are versioned. 3. /usr/lib/ghc should be owned by the packages that install into it, otherwise it hangs around, if all packages have been removed. 4. Rather than remove the .o files in %preun, they should be %ghost'ed 5. The package.conf.old file should also be %ghost'ed by the ghc package otherwise, a complete uninstall leaves something hanging around. 6. The demos should also be packaged. 7. rpmlint complains about non-devel packages requiring devel packages. This should be ignored, otherwise we would have to append -devel to all packages. 8. rpmlint: "W: ghc642-glade summary-ended-with-dot Haskell binding of glade for gtk2hs." Remove the dot. 9. Currently, if someones builds a package requiring the gconf part of gtk2hs, he will need to require ghc642-gconf, even if he doesn't care about the exact version of ghc. Requiring ghc-gtk2hs does the right thing, but only for gtk, glib and cairo. Would "Provides: ghc-gconf" etc... work? (In reply to comment #4) > 1. I modified the spec file so that I can find my way around more easily. > You are free to use it. Thank you! > 2. I think the documentation package should install the documentation > in gtk2hs-doc-%{version} or ghc-gtk2hs-doc-%{version}, since all > directories in /usr/share/doc are versioned. Yes, guess you're right. (It seems to be the default place gtk2hs installs the docs, though personally I quite like it since I have it bookmarked and it is nice not to have to update it every time the version is incremented. On the other hand it is probably cleaner to have the directory versioned.) > 3. /usr/lib/ghc should be owned by the packages that install into it, > otherwise it hangs around, if all packages have been removed. Fixed. > 4. Rather than remove the .o files in %preun, they should be %ghost'ed Good point - fixed. > 5. The package.conf.old file should also be %ghost'ed by the > ghc package otherwise, a complete uninstall leaves something > hanging around. Thanks, will fix that too. > 6. The demos should also be packaged. Good idea: I included them in -doc. > 7. rpmlint complains about non-devel packages requiring devel packages. > This should be ignored, otherwise we would have to append -devel > to all packages. Right - I did ponder renaming them all to -devel packages, but then there is the problem of the .o files used by ghci. > 8. rpmlint: > "W: ghc642-glade summary-ended-with-dot Haskell binding of glade for gtk2hs." > Remove the dot. Fixed. > 9. Currently, if someones builds a package requiring the gconf part > of gtk2hs, he will need to require ghc642-gconf, even if he doesn't > care about the exact version of ghc. Requiring ghc-gtk2hs does the > right thing, but only for gtk, glib and cairo. Would > "Provides: ghc-gconf" etc... work? Well that works, but then the problem is that ghc642-gconf will conflict with ghc641-gconf, etc. An alternative might be to make ghc-gtk2hs pull in all the subpackages perhaps? I updated the submission to: http://people.redhat.com/petersen/extras/ghc-gtk2hs.spec http://people.redhat.com/petersen/extras/ghc-gtk2hs-0.9.10-3.src.rpm (In reply to comment #5) > Yes, guess you're right. (It seems to be the default place gtk2hs installs > the docs, though personally I quite like it since I have it bookmarked and > it is nice not to have to update it every time the version is incremented. I completely agree! However versioning the doc directories is the convention, and unfortunately this convention will hardly change. > > 9. Currently, if someones builds a package requiring the gconf part > > of gtk2hs, he will need to require ghc642-gconf, even if he doesn't > > care about the exact version of ghc. Requiring ghc-gtk2hs does the > > right thing, but only for gtk, glib and cairo. Would > > "Provides: ghc-gconf" etc... work? > > Well that works, but then the problem is that ghc642-gconf will conflict with > ghc641-gconf, etc. An alternative might be to make ghc-gtk2hs pull in all the > subpackages perhaps? Wouldn't that defeat the purpose of splitting off these packages? I wonder if this versioning scheme is really worth the effort. After all there are no shared libraries, where compatibility packages would be necessary. Of course everytime ghc gets updated, the dependent packages must be rebuilt... I am currently building the package in mock... (In reply to comment #6) > > Well that works, but then the problem is that ghc642-gconf will conflict with > > ghc641-gconf, etc. An alternative might be to make ghc-gtk2hs pull in all the > > subpackages perhaps? > Wouldn't that defeat the purpose of splitting off these packages? > > I wonder if this versioning scheme is really worth the effort. After all > there are no shared libraries, where compatibility packages would be > necessary. Of course everytime ghc gets updated, the dependent packages > must be rebuilt... But ghc642-gtk requires ghc642, so what happens when one upgrades to ghc643? I don't think it will be possible to rebuild all ghc built libs immediately after a new ghc release typically. (In reply to comment #7) > But ghc642-gtk requires ghc642, so what happens when one upgrades to ghc643? > I don't think it will be possible to rebuild all ghc built libs immediately > after a new ghc release typically. I see the problem... There is probably no better way out in the current state of affairs. However I just wanted to have written down for the posterity that I do consider it unsatisfactory :-) The package builds fine in mock. Installing the packages works and the demo programs build perfectly well. I find it a little annoying that the doc directories are: ghc642-gtk-0.9.10 ghc-gtk2hs-doc-0.9.10 More consistent would be: ghc-gtk2hs-0.9.10 ghc-gtk2hs-doc-0.9.10 This would mean, that the doc files would go in the ghc-gtk2hs-0.9.10 package which is currently. Is is possible however to install the subpackages without the main package. Probably one could make the package ghc642-gtk require ghc-gtk2hs, so that ghc-gtk2hs is always installed. (In reply to comment #8) > I find it a little annoying that the doc directories are: > ghc642-gtk-0.9.10 > ghc-gtk2hs-doc-0.9.10 > More consistent would be: > ghc-gtk2hs-0.9.10 > ghc-gtk2hs-doc-0.9.10 [Hmm, the situation with ghc is actually similar: html under ghc-6.4.2/ and doc files in ghc642-6.4.2/.] I might be more tempted to just put all the doc files under ghc-gtk2hs-0.9.10/ irrespective of the subpackage they are in (or even gtk2hs-0.9.10/: see below). The reason those doc files are in ghc642-gtk is more of a historical artefact: ghc642-gtk used to be the main ghc642-gtk2hs package and then there were other subpackages like ghc642-gtk2hs-gconf etc. I moved ChangeLog and TODO to the -doc subpackage for now anyway, and AUTHORS and COPYING.LIB to -glib. > This would mean, that the doc files would go in the ghc-gtk2hs-0.9.10 > package which is currently. Is is possible however to install the > subpackages without the main package. Probably one could make > the package ghc642-gtk require ghc-gtk2hs, so that ghc-gtk2hs is always > installed. Hmm, but that then introduces a circular dependency which I think is frowned upon in Fedora packaging circles. I noticed that ChangeLog file is quite big btw: perhaps it should be gzip'ed or just not included? My only concern now with the current package naming (ghc-gtk2hs) is: what happens if/when one day we want to build/package gtk2hs with another Haskell compiler or interpreter (say nhc98, jhc or hugs)? In that sense using a more generic name for the source package (eg just gtk2hs) might be better after all? (We can still have a ghc-gtk2hs subpackage of course even in this case.) (In reply to comment #9) > My only concern now with the current package naming (ghc-gtk2hs) is: what happens > if/when one day we want to build/package gtk2hs with another Haskell compiler or > interpreter (say nhc98, jhc or hugs)? In that sense using a more generic > name for the source package (eg just gtk2hs) might be better after all? > (We can still have a ghc-gtk2hs subpackage of course even in this case.) Yes, that would make sense for the source package. I suppose it is not required to have an main RPM matching the name of the SRPM. I thought, maybe better not split the packages into separate packages for gconf, etc... The largest package is gtk anyway. We would have: ghc-gtk2hs ghc642-gtk2hs nhc98-gtk2hs nhc98-118-gtk2hs etc... This would be much simpler. I think you're right. But let's keep -mozembed separate since mozilla-devel is a very big dep. http://people.redhat.com/petersen/extras/gtk2hs.spec http://people.redhat.com/petersen/extras/gtk2hs-0.9.10-1.src.rpm (building now...) Built fine, but needed to fix a couple more requires: http://people.redhat.com/petersen/extras/gtk2hs.spec http://people.redhat.com/petersen/extras/gtk2hs-0.9.10-2.src.rpm Seems to work well. I could not install the mozembed package due to a new version of mozilla-devel. Don't forget to update this. APPROVED (I opened bug 191676 related to the mozilla-version packaging.) Thanks for the review and improving the packaging this much. :) I imported into cvs and built gtk2hs-0.9.10-1.fc6. Requested FC-4 and FC-5 branches, and added to owners. The package has been renamed to ghc-gtk2hs for F11 in line with the new Haskell Packaging Guidelines. |