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

Re: Renaming of automake to automake1.4

* Branden Robinson (branden@debian.org) wrote:
> 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.

Well the point is they shouldn't do this. They should almost certainly
just depend on a single version of automake, because if some other
version of automake is installed things could very well break. Of
course ideally packages shouldn't depend on automake.

> 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.

Right, so why would you want to do this? It should just build-dep on a
specific version of automake no?

> 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.

Well if someone build-deps on a certain version of automake. This does
make it harder to drop older versions of automake however. But as you
point out ---> Don't build-depend on automake! <---
> 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?

I think he would never go for it :)
> 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.

That is a good point. They are really all trying to do the same thing
so I think the virtual package makes sense, at least to let other
packages recommend or suggest automake packages.

> 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.

I'm trying, feels like swimming upstream sometimes :P

Eric Dorland <dorland@lords.com>
ICQ: #61138586, Jabber: hooty@jabber.com
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 

Attachment: pgp_zigIqnIoK.pgp
Description: PGP signature

Reply to: