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