Bug#852430: apt: even on dist-upgrade, do not consider upgrading a package if its Multi-Arch counterpart cannot
David Kalnischkies dixit:
>In your example the M-A:same packages are version-synced. In fact, apt
>actually notices a version-desync and would not consider the upgrade in
>that case
Yet, I see this behaviour…
> (expect for some corner cases like if the package is dropped
>on that arch and such
(see below)
> or if you explicitly request install of the
>package
That’s of course perfectly correct.
>> • both new versions are there, consistent, but cannot be installed
>> because they depend on a not coïnstallable package (cf. #852408,
>> which is the case for libpsl5 here)
>
>In the current apt solver implementation that is nearly impossible to do
Oh, okay.
>> • the new version is not coïnstallable any more (the local admin
>> SHALL decide in that case which one to throw away)
>
>That is one of the cornercases mentioned above – apt in its usual
>fashion will decide for you based on what your system seems to need
>"most" simply because it would be horrible if we ask the user for input
>each time (one of these days I have to implement a solver which asks the
>user all the time if there is a choice… people are so going to hate it)
No, apt should just hold the package back in such case; asking
the user is for aptitude ;)
By deciding, I meant having the local admin run an explicit
install, remove or purge command, or adding one of the packages
(or the other with a hyphen-minus appended) to the {,dist-}upgrade
command line.
>e.g. the user drops a foreign arch.
Can apt determine this case from “package simply has not built for
the other arch yet”?
If not, I’d prefer it to keep back the package.
>You can specify after (dist/full-)upgrade packages which will be
>installed (or removed if postfixed with a -) and hence help the solver
>figure out "your" solution.
Yes (I asked for this feature), but it doesn’t work in all cases
(although I perfectly understand why in each case it doesn’t), and
sometimes, figuring it out is hard.
Appending a = like in dselect to keep a package held would be
optimal (I started with slink and still use dselect for a number
of package management tasks such as interactively deslacking a
system someone else installed), although…
>There is no "temp" hold at the moment apart
>from asking apt to install a package already installed, but that might
>be added some time in the future.
… dselect’s ‘=’ is a permanent hold; temporary would be more
appropriate here.
Thanks,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Reply to: