* 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
-----BEGIN GEEK CODE BLOCK-----
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+
------END GEEK CODE BLOCK------
Attachment:
pgp_zigIqnIoK.pgp
Description: PGP signature