Re: Proposal for fixing automake (was Re: State of automake packages)
On Fri, Jun 07, 2002 at 03:17:48PM -0400, Eric Dorland wrote:
> > If feasible, my preference would be that the package "automake"
> > contains the latest version (i.e. 1.6). The older version could be
> > stuck in "automake1.4", if need be. [I wonder whether 1.5 is even
> > needed at this point.]
> > The reason that it is the other way around was mainly to avoid lots of
> > breakage during the woody freeze. Since woody is now frozen, we ought
> > to be able to reverse the practice now.
> That's a nice idea, but it means that things that depend on "automake"
> could break the next time a new version of automake is released.
Right, which means things shouldn't depend on "automake". Unfortunately we
weren't expecting upstream to randomly break compatability like that, so
whole swathes of packages _did_ depend on automake. Making "automake.deb"
be automake1.4 worked around this for us since the buildds will always
choose a real package named "automake" in place of the virtual package
provided by automake1.5. You'll probably want to be careful not to break
this for a while, which means not having "automake.deb" be version 1.5
One possibility is to make "automake1.4.deb" be the only package that
provides "automake", and then adjust the conflicts between automake
1.4 and automake 1.5 to ensure they don't get installed together if it
breaks things. If we've got three versions of automake, which aren't
particularly compatible, and which are all used widely, there's probably
not that much value in trying to provide a "canonical" automake.deb.
There's probably no need for a dummy package -- they're only really
useful when you're splitting a package.
Anthony Towns <email@example.com> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``BAM! Science triumphs again!''
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com