Your message dated Sat, 8 Feb 2014 00:53:39 +0000
with message-id
<capq4b8knve5j46xucf1wvs_a+dtmvbjtiwbiunntkqfvtjp...@mail.gmail.com>
and subject line aptitude: Erroneous removal of kernel when upgrading
initrd-tools
has caused the Debian Bug report #186481,
regarding aptitude: Erroneous removal of kernel when upgrading initrd-tools
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.)
--
186481: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186481
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: aptitude
Version: 0.2.11.1-2
Severity: normal
I've come across an odd package constellation where aptitude refused
(incorrectly) to upgrade initrd-tools. I'm running woody with the kernel
from unstable.
Please examine the following interaction:
[root]# apt-show-versions -a -p initrd-tools
initrd-tools 0.1.34 install ok installed
initrd-tools 0.1.32woody.3 stable
initrd-tools 0.1.40 testing
initrd-tools/testing upgradeable from 0.1.34 to 0.1.40
[root]# apt-show-versions -r -p kernel-image
kernel-image-2.4.20-k7/testing uptodate 2.4.20-5
[root]# apt-show-versions | grep testing
kernel-headers-2.4.20/testing uptodate 2.4.20-5
initrd-tools/testing upgradeable from 0.1.34 to 0.1.40
kernel-build-2.4.20/testing uptodate 2.4.20-5
kernel-doc-2.4.20/testing uptodate 2.4.20-5
kernel-image-2.4.20-k7/testing uptodate 2.4.20-5
modutils/testing uptodate 2.4.19-3
kernel-source-2.4.20/testing uptodate 2.4.20-5
[root]# apt-get -s install initrd-tools
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
stat
The following NEW packages will be installed:
stat
1 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Inst stat (3.3-2 Debian:3.0r1a/stable)
Inst initrd-tools (0.1.40 Debian:testing)
Conf stat (3.3-2 Debian:3.0r1a/stable)
Conf initrd-tools (0.1.40 Debian:testing)
In aptitude, initrd-tools 0.1.34 is set on hold. When I mark it for
upgrade, it's shown as
iu initrd-tools
When I hit 'g' now, the following dependencies are 'resolved':
idA initrd-tools 0.1.34
idA kernel-image-2.4.20-k7 2.4.20-5
Of course, the kernel-image should NOT be removed. There are no other
broken dependencies listed. I would've c&p'ed the complete depency trees,
but the program would not let me.
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux elephant 2.4.20-k7 #1 Tue Jan 14 00:29:06 EST 2003 i686
Locale: LANG=C, LC_CTYPE=de_DE@euro
Versions of packages aptitude depends on:
ii apt [libapt-pkg-libc6. 0.5.4 Advanced front-end for dpkg
ii libc6 2.2.5-11.2 GNU C Library: Shared libraries an
ii libncurses5 5.2.20020112a-7 Shared libraries for terminal hand
ii libsigc++0 1.0.4-3 Type-safe Signal Framework for C++
ii libstdc++2.10-glibc2.2 1:2.95.4-11woody1 The GNU stdc++ library
--- End Message ---
--- Begin Message ---
Control: tags -1 + moreinfo
The package versions mentioned are so old that this happened before
snapshots was available, and these Linux series (2.4) are not present
in the archive now. The changelog of current linux images only goes
back to 2.6 in the year 2005. So it's difficult to see what's going
on in term of package dependencies and conflicts.
For me, it looks very possible that there was an incompatibility
between the kernel image and initrd-tools, because for example now
linux-image Breaks initramfs-tools < 0.110~ and depends on >= 0.110~.
In that case, of course upgrading initrd-tools could have forced to
remove the kernel package. Daniel Burrows doesn't seem particularly
surprised and makes questions which seem to imply that he has the same
thing in mind.
So this part does not seem like a bug.
When resolving dependencies and conflicts automatically ('g'), it
chooses a solution which is not very useful, it removes both instead
of for example keeping them both in the same state. But there might
be other dependencies at work behind the scenes which caused this
solution to be prefered over keeping both packages at the same
version.
In any case, this was with an early and very ancient version of
aptitude, and unless more information is provided about why aptitude
decided this, it does not seem sensible or useful to me to try to
follow up.
Since the information was not provided at the time, even when the bug
was replied and this information requested within the same day (I
think that the same hour, accounting for timezone differences), now
that more than 10 years ago went by this seems impossible. There was
only another message 5 years ago, which does not seem particularly
relevant.
So I am closing this bug report now, because I don't think that it's
useful to keep it around. Please reopen if you still have concerns
about it.
Cheers.
--
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
