Re: Bug#685192: apt: redirection handling changes in 0.9.4 may break aptitude
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'.
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.
On Sat, Aug 18, 2012 at 2:53 AM, Raphael Geissert <geissert@debian.org> wrote:
> Now, the easiest way to prevent this kind of conflict would be by adding a
> Depends: apt >= 0.9.4 to libapt-pkg4.12. Not sure how much trouble it would
> cause to a squeeze->wheezy upgrade, as it would force apt to also be
> upgraded when upgrading aptitude (upgrading apt already requires upgrading
> aptitude.) It also introduces a soft dependency loop, but it seems harmless.
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).
The net-result would be that front-ends should depend on 'apt' if they use
the acquire system (some do, even if they don't, packagesearch for example
seems to be such a candidate).
Yet, this might be wrong in the (less likely case) that a user uses only
debtorrent or https which is provided by other packages and therefore the
acquire system could be used without needing the "standard" methods in 'apt'.
So again, a Recommends would be more in order maybe.
On the other hand: A depends could be added automatically with our symbol
file if an acquire symbol is used, recommends can't be added in this way.
Maybe we should add such a feature to dpkg-dev as it could come in handy for
(big) libraries using other tools internally in certain paths.
Might be better than requiring the library user to declare such a relation.
In the end we are talking about an "priority: important" package, so a user
who wants to remove it should be able to handle the pain s/he has to suffer.
'apt' doesn't depend on a network-manager, even through it is likely that
you need some sort of network access to get packages from somewhere else…
Same case if s/he prefers to disable installation of recommends.
And with this back to the initial topic: Adding a recommends, okay?
Best regards
David Kalnischkies
Reply to: