[Bug 1075366] [NEW] Never-MarkAuto-Sections:: oldlibs gives wrong behavior
Steve Langasek
steve.langasek at canonical.com
Tue Nov 6 00:31:21 UTC 2012
Public bug reported:
The /etc/apt/apt.conf.d/01autoremove file includes the following config:
Never-MarkAuto-Sections
{
[...]
"oldlibs";
"restricted/oldlibs";
"universe/oldlibs";
"multiverse/oldlibs";
};
This was added back in 2010, with the following rationale:
message:
add "oldlibs" to the APT::Never-MarkAuto-Sections as its used
for transitional packages
This replaced a previous provisional 'transitional' section.
I don't understand exactly why this was done, but it seems very
incorrect to me. The effect of Never-MarkAuto-Sections is to mark the
*dependencies* of a package in this section as manually installed. This
means that if you're using the historically accurate meaning of the
'oldlibs' section, any library dependencies of an old library will be
marked manually installed, and thus will never be autoremoved when the
old library will no longer be needed. E.g.:
$ apt-cache show libblas3gf
Package: libblas3gf
Priority: optional
Section: libs
Installed-Size: 40
Maintainer: Ubuntu Developers <ubuntu-devel-discuss at lists.ubuntu.com>
Original-Maintainer: Debian Science Team <debian-science-maintainers at lists.alioth.debian.org>
Architecture: all
Source: blas
Version: 1.2.20110419-5
Depends: libblas3
Filename: pool/main/b/blas/libblas3gf_1.2.20110419-5_all.deb
Size: 2920
MD5sum: fb2afb44fdbdaf81d4adac5a509aac68
SHA1: be8056468c7b9668d2f22913853b8babc82af527
SHA256: 067cf1cdbb79372dfb838d534558cb6af29efc9d5d9765b639f9f39026dd2c42
Description-en: Transitional package for libblas
Several minor changes to the C interface have been incorporated.
One can maintain both versions on a system simultaneously to aid
in the transition.
Homepage: http://www.netlib.org/blas/
Description-md5: 8bf7be122ddac6284a83fe69649495b3
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu
Supported: 18m
Task: ubuntu-usb, kubuntu-full, kubuntu-active-full, edubuntu-desktop-kde, edubuntu-desktop-gnome, edubuntu-usb, ubuntustudio-video, ubuntustudio-publishing, ubuntustudio-photography, ubuntustudio-graphics
$ apt-mark showmanual | grep libblas3
libblas3
libblas3gf
$
I think the *intent* was to ensure that when a package becomes a
transitional package, it can then be removed without causing the real
package that is the target of the transition to also be removed. But I
don't think this is a correct interpretation of the 'oldlibs' section;
packages in oldlibs are generally not leaf packages, and their
dependencies are generally real dependencies rather than dependencies
for purpose of a transition. Can we revisit this use of oldlibs?
FWIW, we seem to be doing a poor job in general of getting packages
correctly marked for autoremoval. On my desktop system:
$ for pkg in $(apt-mark showmanual) ; do grep-status -FPackage -X $pkg -a -FSection -X libs -sPackage; done | uniq | wc -l
889
$
I don't think those are all due to this particular bug, but I'm pretty
sure they're almost all wrong. :/
** Affects: apt (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1075366
Title:
Never-MarkAuto-Sections:: oldlibs gives wrong behavior
Status in “apt” package in Ubuntu:
New
Bug description:
The /etc/apt/apt.conf.d/01autoremove file includes the following
config:
Never-MarkAuto-Sections
{
[...]
"oldlibs";
"restricted/oldlibs";
"universe/oldlibs";
"multiverse/oldlibs";
};
This was added back in 2010, with the following rationale:
message:
add "oldlibs" to the APT::Never-MarkAuto-Sections as its used
for transitional packages
This replaced a previous provisional 'transitional' section.
I don't understand exactly why this was done, but it seems very
incorrect to me. The effect of Never-MarkAuto-Sections is to mark the
*dependencies* of a package in this section as manually installed.
This means that if you're using the historically accurate meaning of
the 'oldlibs' section, any library dependencies of an old library will
be marked manually installed, and thus will never be autoremoved when
the old library will no longer be needed. E.g.:
$ apt-cache show libblas3gf
Package: libblas3gf
Priority: optional
Section: libs
Installed-Size: 40
Maintainer: Ubuntu Developers <ubuntu-devel-discuss at lists.ubuntu.com>
Original-Maintainer: Debian Science Team <debian-science-maintainers at lists.alioth.debian.org>
Architecture: all
Source: blas
Version: 1.2.20110419-5
Depends: libblas3
Filename: pool/main/b/blas/libblas3gf_1.2.20110419-5_all.deb
Size: 2920
MD5sum: fb2afb44fdbdaf81d4adac5a509aac68
SHA1: be8056468c7b9668d2f22913853b8babc82af527
SHA256: 067cf1cdbb79372dfb838d534558cb6af29efc9d5d9765b639f9f39026dd2c42
Description-en: Transitional package for libblas
Several minor changes to the C interface have been incorporated.
One can maintain both versions on a system simultaneously to aid
in the transition.
Homepage: http://www.netlib.org/blas/
Description-md5: 8bf7be122ddac6284a83fe69649495b3
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu
Supported: 18m
Task: ubuntu-usb, kubuntu-full, kubuntu-active-full, edubuntu-desktop-kde, edubuntu-desktop-gnome, edubuntu-usb, ubuntustudio-video, ubuntustudio-publishing, ubuntustudio-photography, ubuntustudio-graphics
$ apt-mark showmanual | grep libblas3
libblas3
libblas3gf
$
I think the *intent* was to ensure that when a package becomes a
transitional package, it can then be removed without causing the real
package that is the target of the transition to also be removed. But
I don't think this is a correct interpretation of the 'oldlibs'
section; packages in oldlibs are generally not leaf packages, and
their dependencies are generally real dependencies rather than
dependencies for purpose of a transition. Can we revisit this use of
oldlibs?
FWIW, we seem to be doing a poor job in general of getting packages
correctly marked for autoremoval. On my desktop system:
$ for pkg in $(apt-mark showmanual) ; do grep-status -FPackage -X $pkg -a -FSection -X libs -sPackage; done | uniq | wc -l
889
$
I don't think those are all due to this particular bug, but I'm pretty
sure they're almost all wrong. :/
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1075366/+subscriptions
More information about the foundations-bugs
mailing list