Re: Bug#685192: apt: redirection handling changes in 0.9.4 may break aptitude
H David,
On Tuesday 21 August 2012 08:50:34 David Kalnischkies wrote:
> For clarity: This partial upgrade thing effects not only aptitude, but
> APT itself and "just" by extension all front-ends even if the message
> just talks about how aptitude is unable to handle the internal change in
> libapt and how it talks to his own http-method shipped in 'apt'.
As far as I tested, it doesn't affect APT as long as it isn't a partial
upgrade from the experimental version that had a separate libapt-pk4.10.
Upgrading apt will also pull in libapt-pkg4.12, and at the time the new
packages are unpacked no new http method is started. The next call to APT
would already use the new versions of apt and the http method.
Am I missing something?
> And I doubt that a bug containing the words "partial upgrade" and
> "unofficial sources" (which http.debian.net still is, even as a
> well-recieved "mirror" of official content) fits very well in the
> severity "grave" bucket, but I let it slight for the moment.
Just one fact:
I have seen more than one mirror, part of the Debian mirrors network,
redirect from /debian/ to /pub/linux/debian/ and stuff like that.
At the moment there should be none of those in the mirrors list, but users
who had picked one of those mirrors before the path was changed would be
affected.
That said, if you disagree with the severity, feel free to change it.
Not sure how common Michael Prokop's scenario is with FAI. He was using a
minimal debootstrapped chroot and then upgrading it.
> I think Depends are a bit hard in that case. It's not only a loop, but
> libapt-pkg can be used without the method-binaries in a lot of cases, so
> a Recommends: apt (>= ${binary:Version})
> feels more appropriated and should trigger an upgrade of 'apt' in this
> partial upgrade situation as well (as long as the installation of
> Recommends are not disabled) without negative consequences on the
> installation order.
>
>
> The only thing not covered by this Recommends is that you can still
> remove apt from your system and possibly break aptitude (and other
> packages using the acquire-system from libapt) - for any libapt user
> this will be equal to the removal of an essential package through,
> however the specific front-end handles this (apt-get is e.g. very vocal
> about that).
If you do consider those cases, then Breaks should probably be used instead.
Recommends is not enough even for the scenario where this bug was
reproduced: grml - recommends are disabled by default.
I haven't tested a squeeze->wheezy upgrade with Breaks, though. Will try to
get around it today so that I can report back...
> Same case if s/he prefers to disable installation of recommends.
> And with this back to the initial topic: Adding a recommends, okay?
... because I don't think Recommends is appropriate.
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Reply to: