Re: APT and Versioned Obsoletes

On Wed, Aug 18, 2004 at 11:08:46AM -0300, Gustavo Niemeyer wrote:
> > Yes, that's newer rpms do have this nice "feature" that effectively
> > turn any versioned Provides to a versioned Obsoletes, e.g.
> > 
> > Provides: foo = bar implies Obsoletes: foo <= bar
> 
> That's a big surprise to me as well.
> 
> > Why this was defined as a wanted features, I don't know, it looks
> > quite broken to me, as there are valid cases, where a Provides should
> > not imply an Obsoletes, like in the case of allowing multiple versions
> > of the same package to exist. :(
> 
> It looks broken to me as well. Using Provides and Obsoletes together
> was always an option, if that was the intent.
> 
> [...]
> > Wrt apt: It would be nice if apt were aware about the fact of implicit
> > Obsoletes for rpm >=  4.2.1 (?) and display that this package
> > will be removed. It has bitten quite a lot of folks :(
> 
> These are considered upgrades anyway, so I belive that based
> on current APT practice, it won't show up even if we mark it
> as an obsoletes relation.

Won't there be "package foo removed (due to bar)"?

> OTOH, I'm curious about what will happen with dependencies on the
> package being removed. This might be a reason for APT to follow the
> relation.

The rpm transaction fails if the implicitely obsoleted package is
still holding dependencies that no new packages resolves. :(

Having APT follow the broken algorithm will at least make that package
be held back.

But the true fix would be to revert this rather useless feature. It
only reduces the degrees of freedom in packaging, as Jeff's example
shows.
-- 
Axel.Thimm at ATrpms.net

_______________________________________________
apt-rpm mailing list
[email protected]
http://distro2.conectiva.com.br/mailman/listinfo/apt-rpm

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBI5oxQBVS1GOamfERAuTvAKCGroI45HBRKVfmjbPNpw+GOQ4bXwCghnHR
U74AAjHLwaMe4rTb5IPKh6Q=
=KAJy
-----END PGP SIGNATURE-----