Contol: owner -1 !
Contol: fixed -1 aptitude/0.8-1
Contol: close -1
Hi,
2014-08-08 09:23 Vincent Lefevre:
Package: aptitude
Version: 0.6.11-1
Severity: normal
I type 'U', and get for "linux-libc-dev:i386":
Some dependencies of linux-libc-dev:i386 are not satisfied: ▒
▒
▒
* linux-libc-dev:i386 breaks linux-libc-dev (!= 3.14.13-2) ▒
▒
▒
The following packages conflict with linux-libc-dev:i386: ▒
▒
▒
* linux-libc-dev breaks linux-libc-dev:i386 (!= 3.14.15-1) ▒
The root cause of this is that multi-arch packages need to be installed
with the same exact version, and this is a Debian-wide problem affecting
upgrades with multi-arch and when the different arches have these
packages out of sync (e.g. when some buildds are slower than others, one
arch fails to build the package, or more importantly, when binNMUs are
different for arches that one wants to have installed).
There's some discussion about this in #663134, and several development
mailing lists, for example proposing to solve this problem at least for
the binNMUs by keeping all NMUs in sync (always bumping numbers, even if
some arches don't need it).
This is a problem that only affects unstable (and possibly testing in
some cases, but I don't think that very often), so I'm not sure if this
is going to be addressed or if things will keep working as they are now.
and when I type 'g':
iF gnupl│Some packages were broken and have been fixed: │
iF gnupl│ │
iF gnupl│Remove the following packages: │
i graph│libc6-dev:i386 │
iF gthum│libstdc++-4.8-dev:i386 │
iF gthum│linux-libc-dev:i386 │
i libpa│ │
i libxd│Install the following packages: │
iF libxm│libc++-dev:i386 [1.0~svn205159-1 (testing, unstable)] │
iF libxm│libc++-helpers [1.0~svn205159-1 (testing, unstable)] │
iF libxm│libc++1:i386 [1.0~svn205159-1 (testing, unstable)] │
iF libxm│ │
i linux│Keep the following packages at their current version: │
i metac│expect [5.45-5 (now)] │
i metac│graphviz [2.26.3-17.1 (now)] │
iF udev │libgraphviz-dev [2.26.3-17.1 (now)] │
│libgvc6 [Not Installed] │
These pac│libmetacity-private1 [Not Installed] │rent ▒
state to │libpathplan4 [2.26.3-17.1 (now)] │ ▒
│libsystemd-daemon0 [204-14 (now)] │ ▒
This grou│libsystemd-journal0 [204-14 (now)] │ ▒
│libsystemd-login0 [204-14 (now)] │ ▒
If you se│libudev1 [204-14 (now)] │ar in ▒
this spac│libxdot4 [2.26.3-17.1 (now)] │ ▒
│linux-libc-dev [3.14.13-2 (now, testing)] │ ▒
│metacity [1:2.34.13-1 (now)] │ ▒
│metacity-common [1:2.34.13-1 (now)] │ ▒
│ │ ▒
│Leave the following dependencies unresolved: │ ▒
│libgcc-4.8-dev:i386 recommends libc6-dev:i386 (>= 2.13-5) │ ▒
│ [ Ok ] │ ▒
I don't understand why linux-libc-dev:i386 is removed, since
linux-libc-dev is kept to its current version.
This is because 'g' takes the first solution coming from the resolver
(if the user didn't choose one explicitly), and before the 0.8 series
the first solutions offered were notouriously "removal-happy".
In a system with linux-libc-dev = 4.5.2-1, with 4.5.3-1 as candidate,
and trying to install linux-libc-dev:i386 (candidate 4.5.3-1), aptitude
will mark linux-libc-dev:i386 for install and linux-libc-dev for
upgrade. If one decides to keep linux-libc-dev at its current version,
it conflicts with linux-libc-dev:i386, and when pressing 'g' the
solution is:
│ Some packages were broken and have been fixed: │
│ │
│Keep the following packages at their current version:│
│linux-libc-dev:i386 [Not Installed] │
If I had both linux-libc-dev and :i386 installed with 4.5.2-1, and an
upgrade for :i386 was available but not for the :amd64 one (a situation
analogous to the one presented here), the first solution of the resolver
nowadays would be also to "Keep the following packages at their current
version".
Then in this new screen, for "linux-libc-dev:i386":
linux-libc-dev:i386 will be automatically removed because of dependency errors:▒
and no dependency errors are listed. Indeed, this is because aptitude
was wrong when deciding to remove it. And I can type '+' on it to
cancel the removal without any error.
After the remedial actions forcefully taken by the resolver,
linux-libc-dev was kept at "[3.14.13-2 (now, testing)]", so trying to
keep linux-libc-dev:i386 at 3.14.13-2 was OK, but only after keeping
linux-libc-dev at the same version (instead of upgrading all packages,
as originally requested).
linux-libc-dev:i386 has been proposed for removal uneccessarily, when
keeping linux-libc-dev at its current version would suffice. (This was
probably one of the solutions offered, although not the first).
2014-08-09 06:19 Daniel Hartwig:
This is apparently due to aptitude's incomplete multiarch support.
The program should be upgrading groups like this in lockstep, before
the problem resolver gets involved.
Will get that fixed for Jessie.
So my understanding of the problem is slightly different.
The root cause (multi-arch packages out of sync) is unsolvable by
aptitude, and the best thing that we can do is to attempt to upgrade
packages in lock-step (as it happens in recent versions), and give less
drastic solutions to conflicts as first choices (something addressed in
0.8).
So closing the bug as fixed with that version number.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
