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