[Bug 189197] Review Request: ghc-gtk2hs

[bugzilla at redhat.com]

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 at redhat.com  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.