HEADS UP: patches, package versions, and cabal-install
igloo at earth.li
Mon Dec 8 13:06:01 EST 2008
On Mon, Dec 08, 2008 at 04:28:31PM -0000, Claus Reinke wrote:
> >>Could the array/containers version bumps be done soon, please,
> >As far as I can see there are no code changes in the array package. I
> >guess what we're really trying to do is work around cabal-install
> >replacing libraries with ABI-incompatible builds?
> array had dependency/import changes since the last version change,
> same for containers, which also had export changes:
> Thu Nov 13 14:48:43 GMT Standard Time 2008 Duncan Coutts <duncan
> * Turns out syb is not needed at all
> M ./Data/Array.hs -2
> M ./array.cabal -2
This only removes a package dep and some comments:
hunk ./Data/Array.hs 62
---import Data.Generics.Instances () -- To provide a Data instance
---import Data.Generics.Basics () -- because the Data instance is an orphan
hunk ./array.cabal 18
- if !impl(nhc98)
- build-depends: syb
I don't know if the package dep removal could have contributed to
cabal-install reinstalling array, but I suspect it's more likely that
the problem was that cabal-install wanted it to depend on base-3 instead
> Thu Oct 2 09:24:11 GMT Daylight Time 2008 'Jose Pedro Magalhaes <jpm
> * remove unnecessary Data.Generics.* imports
> M ./Data/Array.hs -2 +2
This is in the 6.10.1 release, and in the package on hackage.
> Sat Sep 20 16:57:39 GMT Daylight Time 2008 Ian Lynagh <igloo earth.li>
> * Bump version number to 0.2.0.0
> M ./array.cabal -1 +1
The version-bumping patch doesn't determine what the contents of the
version are. Apart from anything else, patches can be reordered in
darcs. There should be a tag defining what's in the version, but it
looks like I forgot to do that this time round. I'll go back and add the
tags, but FYI they'll contain the same patches as the
GHC 6.10.1 release
> >We could do that by bumping the 4th component of each library, so that
> >that version isn't on hackage and thus cabal-install can't replace it.
> that sounds similar to a patch-level, only that it isn't, if it isn't going
> with each patch.
I don't think it is common for patch-level to go up for each patch,
especially in the open source world. Normally it's only bumped on each
And having the version number change with each patch would be a pain to
do, and would mean that we wouldn't be able to cherry-pick patches as
they'd all depend on the previous one.
> Does cabal allow for labels in version numbers, to
> indicate an unstable version phase (-head/-unstable)?
> >However, once the VCS changeover happens the plan is to use released
> >versions of all the libraries, which means that we can't do that (unless
> >we mangled their version numbers or something).
> Won't every released version have its own number anyway?
Yes, but that won't help with the problem of cabal-install replacing an
installed version with an ABI-incompatible build of the same version.
More information about the Cvs-ghc