Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ghc-gtk2hs https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189197 ------- Additional Comments From petersen@xxxxxxxxxx 2006-04-27 07:29 EST ------- (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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review