Your message dated Sat, 18 Feb 2017 21:19:35 +0100
with message-id <[email protected]>
and subject line Re: aptitude: Auto-flagged dependencies of a renaming package
get lost during an upgrade
has caused the Debian Bug report #800459,
regarding aptitude: Auto-flagged dependencies of a renaming package get lost
during an upgrade
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
800459: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800459
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: aptitude
Version: 0.7.2-1
Severity: normal
Dear Maintainer,
There are a quite number of bug reports in the BTS about the loss of the
Auto flag of package dependencies in several scenarios using aptitude.
I've found a totally reproducible scenario that might or might not be
the root cause of one or several of those bugs, so I've decided to open
a new separate bug report for this case. Please merge it to the
appropiate bug report if you consider it's the same problem.
Also note that this is the only case that I've found that causes the
loss of the Auto flag (at least nowadays), but that doesn't mean that
there is the only one that exists.
In all the scenarios that I've found, an `aptitude upgrade' that caused
the loss of the Auto flags always have a renaming package involved, such
as python-pelican to pelican, or the transition from libav* to
libav*-ffmpeg. To prove my suspicions, I built a synthetic test case in
which a package called A with several dependencies is renamed (and
replaced) by a package A'. The exact dependencies between packages I've
choose to test are better described with a diagram (more about the
selected configuration later):
http://www.escomposlinux.org/jcantero/ld/images/aptitude-bug-3.png
(Grey box means the package has the Auto flag set)
For the procedure of renaming the package I've followed the
recommendations and practices described in the Debian wiki[1].
The results show that aptitude loses the Auto flag of all the
dependencies of the renaming package A', not only the direct
dependencies that migrate from the "Depends:" of package A to the
"Depends:" of package A', but also the dependencies of these
dependencies, and so on (recursively). This applies in the above diagram
to B, C, D, E, F, G, H and J packages.
But there is one important exception to this behavior: a package with a
reverse dependence from a different package doesn't lose its Auto flag.
This seems to happen regardless of its position in the dependency graph.
In the above diagram the package Z prevents D (and therefore H) to lose
their Auto flag.
The final state of the package Auto flags after the `aptitude upgrade'
is:
http://www.escomposlinux.org/jcantero/ld/images/aptitude-bug-4.png
You can build and test yourself that configuration (or one equivalent),
for instance using equivs to create the packages. I have done my own
source packages (you can find them in my git repo[2] ready to be built
with a `make packages') and all the tests that I've done with them
confirm the hypothesis. I can send you the logs with the output of the
different aptitude commands if you want, but you should be able to
reproduce them by your own using the information provided.
One more thing: I've tested apt-get too, and it's not affected. After
the `apt-get upgrade' the Auto flags remains in place.
[1]: https://wiki.debian.org/Renaming_a_Package
[2]:
https://github.com/javiercantero/apt-repo-testsuite/tree/master/tests/renaming-package
-- Package-specific info:
Terminal: xterm
$DISPLAY is set.
which aptitude: /usr/bin/aptitude
aptitude version information:
aptitude 0.7.2 compiled at Sep 19 2015 16:51:55
Compiler: g++ 5.2.1 20150903
Compiled against:
apt version 4.16.0
NCurses version 6.0
libsigc++ version: 2.4.1
Gtk+ support disabled.
Qt support disabled.
Current library versions:
NCurses version: ncurses 6.0.20150810
cwidget version: 0.5.17
Apt version: 4.16.0
aptitude linkage:
linux-vdso.so.1 (0x00007ffeedb57000)
libapt-pkg.so.4.16 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.16
(0x00007fc62c69a000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5
(0x00007fc62c46a000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5
(0x00007fc62c23f000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0
(0x00007fc62c039000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3
(0x00007fc62bd3a000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
(0x00007fc62ba6c000)
libboost_iostreams.so.1.58.0 =>
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.58.0 (0x00007fc62b853000)
libxapian.so.22 => /usr/lib/libxapian.so.22 (0x00007fc62b451000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fc62b233000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007fc62aeb8000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc62abb7000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007fc62a9a0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc62a5f7000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fc62a3f4000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc62a1ef000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc629fd4000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0
(0x00007fc629dc4000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fc629ba0000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fc629998000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fc629792000)
/lib64/ld-linux-x86-64.so.2 (0x0000557904ff3000)
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (600, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.1.8-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages aptitude depends on:
ii aptitude-common 0.7.2-1
ii libapt-pkg4.16 1.0.10.2
ii libboost-iostreams1.58.0 1.58.0+dfsg-3+b1
ii libc6 2.19-22
ii libcwidget3v5 0.5.17-4
ii libgcc1 1:5.2.1-17
ii libncursesw5 6.0+20150810-1
ii libsigc++-2.0-0v5 2.4.1-2
ii libsqlite3-0 3.8.11.1-1
ii libstdc++6 5.2.1-17
ii libtinfo5 6.0+20150810-1
ii libxapian22v5 1.2.21-1.2
Versions of packages aptitude recommends:
pn aptitude-doc-en | aptitude-doc <none>
pn libparse-debianchangelog-perl <none>
ii sensible-utils 0.0.9
Versions of packages aptitude suggests:
pn apt-xapian-index <none>
pn debtags <none>
ii tasksel 3.33
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 0.8.3-1
Hi Javier,
2016-09-05 17:38 Javier Cantero:
Package: aptitude
Followup-For: Bug #800459
Dear Maintainer,
The bug is fixed in the current version of testing (0.8.3). I haven't
checked it using the versions from 0.7.6 to 0.8.2 (since those versions
never went to testing) so I don't know what specific version/patch fixed
it. But it's fixed now and the Auto flags don't get lose with the
described situation during an `aptitude upgrade`.
Anyway I'll keep monitoring if any package loses the Auto indicator.
Thanks for following-up, and for the detailed original bug report in the
first place.
I had saved it as one of the reports to pay special attention to when
reviewing the remaining problems of the missing auto-flags, due to it
being very detailed. In previous versions of aptitude (the ones that
didn't enter testing, as you said), I had fixed some of the cases, but
not all.
I hoped to do continue with the bug-squashing by mid/late summer, but in
the end it was not possible for me to work much on aptitude in the last
6 months.
Unfortunately, it seems that there are still several cases of auto-flag
being mishandled or lost at some point... so the bug hunting will have
to continue :)
Thanks again!
--
Manuel A. Fernandez Montecelo <[email protected]>
--- End Message ---
_______________________________________________
Aptitude-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
