rpm package naming (ghc, ghc6 and ghc5)

[Jens Petersen]

Hi,

Thanks for already updating the 6.0 rpm links again, Simon. :-)

[ After much experimenting, the current package is the ghc-6.0-7 package
uploaded yesterday.  There is also a ghc5 package (ghc5-5.04.3-4) that
can also be installed/upgraded in parallel without conflicts (since it
doesn't provide "ghc"). See the ChangeLog file in
http://haskell.org/~petersen/rpms/ghc/ to read about the latest
packaging changes. ]

2003年06月13日(金)の21時31分に Simon Marlow 曰く:
>  > 2003年06月13日(金)の17時53分に Jens Petersen 曰く:
> > Thinking about it more, I realised that of course what is really being
> > numbered here is the interface version number of the hi files 
> > (the "ABI" version if you like), so perhaps it would be better to name 
> > the packages ghc6000 and ghc5043?

> The reason for including the version number in the name is so you can
> have side-by-side installation of several different versions of GHC,
> right?

Yep. Also from the point of view of packaging ghc-packages of haskell
libraries, there's a need to label the ghc version required both for
users and rpm. The motivation was basically the requirement to be able
to update different versions of ghc separately without conflicts and
without have to re-install ghc library package rpms already installed
for the particular ghc versions involved.  So for binary packages of ghc
libraries at least I would argue that a more fine-grained naming scheme
makes sense as long as ghc is going to be breaking the ABI with every
minor release.  A package name like "somelib-ghc6" isn't really clear
enough, the ABI version needs to be made more explicit: eg by say
"somelib-ghc60".

> Is there really a demand for having several different patchlevel
> releases installed at the same time?

Well for patchlevel releases, I agree that re-compiling libraries and
applications usually shouldn't be too bad, but I suppose one could
imagine times when some libraries/programs need tweaking before they'll
work with the latest patchlevel release.  So having the capability for
parallel install doesn't seem like a bad thing.

> On FreeBSD, for example, we currently allow both GHC 6.x and 5.x to be
> installed side-by-side, but nothing finer grained than that.  There
> doesn't seem to be a precedent for doing this in RPMs - there are only
> a few cases where I have multiple versions of the same package
> installed together, and they tend to be confined to major releases
> (eg. python & python2).

Ok, while I agree the ghc%{version} naming seems like overkill, I still
feel ghc5 and ghc6 is a little on the coarse-grained side.

As I mentioned at the beginning, currently there is a ghc-6.0 package
and a ghc5-5.04.3 package, which can both be installed and upgraded
independently without conflicts.  (In order for this to work, because of
rpm ideosyncracies, ghc5 doesn't currently provide "ghc", only the ghc
package does that, otherwise it leads to conflicts when upgrading them
apparently.)  Therefore I would like to propose that every ghc rpm
package should provide "GHC" instead of "ghc", and that rpm packages of
ghc libraries should require a version of "GHC" rather than "ghc".  (The
current rpms don't yet provide "GHC", but I'm planning to add that in
the next builds.)  Does this sound reasonable, or does anyone have a
better idea?

After this is settled I plan to build a ghc60-6.0 package, so that after
the next release is out people can simply update ghc-6.0 to ghc60 and
continue using their 6.0 library rpms, while transitioning to the new
release using a new ghc-6.0.1 rpm package say.  In fact this mechanism
could also be used for testing rpms of snapshot and cvs builds.

Jens