[Bug 1075366] [NEW] Never-MarkAuto-Sections:: oldlibs gives wrong behavior

Daniel Hartwig mandyke at gmail.com
Wed Nov 7 01:59:18 UTC 2012


On 7 November 2012 06:25, Steve Langasek <steve.langasek at canonical.com> wrote:
>> - upgrading packages with python-aptdaemon (e.g. via
>>   software-center). [2]
>
> I use update-manager for my upgrades, not software-center.  Does the same
> issue apply?

Looking quickly at UpdateManager/backend/InstallBackendAptdaemon.py,
it's commit method does appear to request upgrades from aptdaemon (via
pkg_upgrades argument), which is where the problem is.  Without
looking at it further, I'd say that the issue does apply.

The patch in the linked bug report shows clearly that the code is
wrong, although actually exposing the issue in tests took some time
(may be due to the workarounds in pkgDepCache::MarkInstall to "fix"
aptitude).

>
> I think a lot of my issue probably comes to the way I reinstalled my system
> to a new hard drive, using dpkg --get-selections rather than apt-clone.

There is that also.

-- 
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