[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Renaming of automake to automake1.4



On Thu, Oct 17, 2002 at 09:39:25PM -0400, Eric Dorland wrote:
> Wow, the last thing I expected was people to have a problem with the
> name :) Well I'm open to other suggestions if necessary. I think its a
> good virtual package name in that it almost certainly won't conflict
> with any actual package's name.

Well, how about just "automake", since it's becoming a pure virtual
package[1]?

The packages which B-D on automake* will need to do the "real | virtual"
thing for pure virtual packages anyway.

I.e., the packages on your list should be updated to
	Build-Depends: automake1.4 | automake

Let's consider the two partial upgrade scenarios:

1) woody user pulls down a sid/sarge version of one of the affected
packages, e.g. abiword
	abiword in sid/sarge will Depend on automake1.4 (or automake1.5,
	or 1.7, etc.), and apt-get build-dep will pull in the required
	automake package.

2) woody user pulls down a sid/sarge version of automake{1.5,1.7}
	Hmm, well, these will "Provide: automake" and the woody version
	of abiword will suddenly become unbuildable, because automake 1.5
	and 1.7 will presumably vomit when they encounter
	automake1.4-isms.

These are "merely" build-dependencies, so I don't actually think this is
a serious problem.  As you said, people shouldn't be Build-Depending on
automake anyway.  I don't think there is all that much we can do to
insulate people from these sorts of problems with automake breaking
compatiblity so frequently.

To mitigate the potential fun and excitement, I suppose we could always
ask the Stable Release Manager if he'd be willing to allow uploads of
the affected packages to stable-updates that would either:
	1) drop the B-D on automake altogether
	2) Build-Conflict with automake1.5, automake1.7

What do you think?

As a final suggestion, if there are really that many Makefile.am's in
the world that will only work with specific versions of automake,
perhaps we shouldn't have a virtual package at all.  The existence of a
virtual package implies a degree of interchangeability among the
packages that provide it.  If that's just not the case with automake, we
shouldn't try to advertise it.

After all, we do not have shared library packages Provide versions of
themselves with the version number stripped off.

Thanks for your efforts in trying to steer us away from the auto*
shoals.

[1] man apt-cache

-- 
G. Branden Robinson                |    I just wanted to see what it looked
Debian GNU/Linux                   |    like in a spotlight.
branden@debian.org                 |    -- Jim Morrison
http://people.debian.org/~branden/ |

Attachment: pgpKtJ1fVLYbb.pgp
Description: PGP signature


Reply to: