Ubuntu

aptitude has private package holds, should use dpkg

Reported by Jonas Ådahl on 2006-12-11
118
This bug affects 15 people
Affects Status Importance Assigned to Milestone
Software Updater
Invalid
Undecided
Unassigned
aptitude (Debian)
Confirmed
Unknown
aptitude (Ubuntu)
Medium
Unassigned
Declined for Dapper by Sebastien Bacher
Declined for Hardy by Sebastien Bacher
Declined for Jaunty by Sebastien Bacher
Declined for Karmic by Sebastien Bacher
Declined for Lucid by Sebastien Bacher
Declined for Maverick by Sebastien Bacher

Bug Description

When I make packages held back (I don't want to upgrade due to a bug in the newest version which makes it unusable) in aptitude, update-manager still wants to upgrade this package. Apt-get and aptitude do the right thing though.

  Somehow I never got an email about this bug, but whatever. Fixed in CVS.

  The running of apt-listchanges is harmless, and occurs because
aptitude doesn't check whether anything is to be done before telling apt
to install/remove packages (so all the hooks get called)
  This will also occur if, eg, you run an "upgrade" when nothing is
upgradable.

  Daniel

--
/-------------------- Daniel Burrows <email address hidden> -------------------\
| "By Elbereth and Lúthien the fair, you shall have neither the Ring, nor me!" |
| -- Frodo Baggins |
\---------------------- A duck! -- http://www.python.org ---------------------/

Download full text (3.4 KiB)

Package: aptitude
Version: 0.2.11.1-2
Followup-For: Bug #137771

Hi Daniel,

I just wanted to followup on

a)#137771, the bug which Joey Hess earlier reported.

I have noticed this problem as well, and the related issue

b) that if you put a package (say foo) on hold in the traditional way,
# echo "foo hold" | dpkg --set-selections
this is completely ignored by aptitude.

This works with apt-get, and people moving from apt-get to aptitude
are going to expect this behaviour. Looking at the Debian user lists
this is the most popular way of putting a package on hold.

>From what Joey Hess says, it appears that this information is stored
in the file /var/lib/dpkg/status. I don't know much about how dpkg
works, but this is confirmed by my own observations.

Anyway, it seems that apt-get does not store the held state of
packages internally. Instead, it reads /var/lib/dpkg/status.

Currently, aptitude stores the held status of packages in some
internal database. I am guessing this may be
/var/lib/aptitude/pkgstates. Would it not be best if it behaved like
apt-get, ie. reading information from /var/lib/dpkg/status?

This would solve a) and b) at one go. Anything else would mean that
dpkg/apt-get were not aware of when a package was being held by
aptitude and vice-versa. Note this is based on my understanding, which
may be incorrect.

I see that you responded to Joey Hess's report saying the bug had been
fixed, but it is still open, and I certainly see the behaviour he
reported. Also, I don't understand your reply to him. You say

"The running of apt-listchanges is harmless, and occurs because
aptitude doesn't check whether anything is to be done before telling
apt to install/remove packages (so all the hooks get called)
This will also occur if, eg, you run an "upgrade" when nothing is
upgradable."

Could you spell this out for me, please?

I have another side comment. When I put a package (say slrn) on hold,
then when I run apt-get install slrn I get

The following held packages will be changed:
  slrn
The following packages will be upgraded
  slrn

It seems that directly doing an install forces a change in the status
of the package. This might be described as a "soft hold".

The behaviour of aptitude using its own hold is similar, except that
it does not warn about the package having being in the held state. (It
might be a good idea to add a warning as apt-get does). This might be
called a "softer hold". :-)

I would like to see a "hard hold", where short of explicitly unholding
the package, the package will not be upgraded. This would make it
unlikely that you would accidentally nuke a painfully hand-compiled
(over several hours) package :-) Perhaps you could put a config
option, to toggle the behaviour of aptitude between a "soft" and
"hard" hold.

Are you planning to work actively on aptitude over the summer?

                                 Best regards, Faheem Mitha.

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux Chrestomanci 2.2.19pre17 #1 Tue Mar 13 22:37:59 EST 2001 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages aptitude depends on:
ii apt [libapt-pkg-libc6.2- 0.5.4 Advanced front-end for ...

Read more...

On Sat, May 04, 2002 at 12:17:32AM -0400, Faheem Mitha <email address hidden> was heard to say:
> b) that if you put a package (say foo) on hold in the traditional way,
> # echo "foo hold" | dpkg --set-selections
> this is completely ignored by aptitude.

  Could you give me a reproducible test case? This has always worked
for me.

> Currently, aptitude stores the held status of packages in some
> internal database. I am guessing this may be
> /var/lib/aptitude/pkgstates. Would it not be best if it behaved like
> apt-get, ie. reading information from /var/lib/dpkg/status?

  No, it wouldn't. dselect's states are not in general equivalent to
aptitude's, although they're similar.

> I see that you responded to Joey Hess's report saying the bug had been
> fixed, but it is still open, and I certainly see the behaviour he

  I think it was a typo, sent to the wrong bug. Another joeyh bug
filed at about that time was describing something that had been fixed.

> The behaviour of aptitude using its own hold is similar, except that
> it does not warn about the package having being in the held state. (It
> might be a good idea to add a warning as apt-get does). This might be
> called a "softer hold". :-)

  That might be nice.

> I would like to see a "hard hold", where short of explicitly unholding
> the package, the package will not be upgraded. This would make it
> unlikely that you would accidentally nuke a painfully hand-compiled
> (over several hours) package :-) Perhaps you could put a config
> option, to toggle the behaviour of aptitude between a "soft" and
> "hard" hold.

  That might also be nice.

> Are you planning to work actively on aptitude over the summer?

  It depends on how much I'm working this summer. I don't know yet.

  Daniel

--
/-------------------- Daniel Burrows <email address hidden> -------------------\
| After the game, the king and |
| the pawn go in the same box. |
| -- Italian proverb |
\---------------------- A duck! -- http://www.python.org ---------------------/

On Sat, 4 May 2002, Daniel Burrows wrote:

> On Sat, May 04, 2002 at 12:17:32AM -0400, Faheem Mitha <email address hidden> was heard to say:
> > b) that if you put a package (say foo) on hold in the traditional way,
> > # echo "foo hold" | dpkg --set-selections
> > this is completely ignored by aptitude.
>
> Could you give me a reproducible test case? This has always worked
> for me.

That is strange. I get this behaviour with every package I tried. Ok, here
is an example of a run (with vim).

Chrestomanci:~# dpkg --get-selections | grep vim
vim hold
Chrestomanci:~# aptitude upgrade
Reading Package Lists... Done
Building Dependency Tree
Reading extended state information... Done
The following packages have been kept back:
  apt-howto debian-policy links openafs-client
The following packages will be upgraded:
  vim
1 packages upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
Need to get 3751kB of archives. After unpacking 1417kB will be used.
Do you want to continue? [Y/n/e/d/v/action/?]

As you can see, I have vim listed as held, but aptitude upgrade is still
upgrading vim (btw, the flags for vim in aptitude are iu.) So, vim is not
marked as held by aptitude.

I can't imagine why you would get different behaviour.

aptitude version is 0.2.11.1, the precompiled binary. Pretty much all
other related packages are whatever is in woody (which I am tracking). The
only other thing I can think of is that the config file (which is old) is
causing something funny to happen, so I am including it below.

                                 Best regards, Faheem Mitha.

(.aptitude/config)

aptitude "";
aptitude::UI "";
aptitude::UI::Package-Header-Format "%N %n #%B %u %o";
aptitude::UI::Package-Status-Format "%d";
aptitude::UI::Package-Display-Format "%c%a %p #%v%V";
aptitude::UI::Default-Grouping "filter(missing),task,status,section(subdir,passthrough),section(topdir)";
aptitude::UI::Advance-On-Action "false";
aptitude::UI::Description-Visible-By-Default "true";
aptitude::UI::Minibuf-Download-Bar "true";
aptitude::UI::Prompt-On-Exit "true";
aptitude::UI::Exit-On-Last-Close "true";
aptitude::UI::Incremental-Search "true";
aptitude::UI::Minibuf-Prompts "true";
aptitude::UI::Menubar-Autohide "false";
aptitude::UI::HelpBar "true";
aptitude::UI::New-Package-Commands "false";
aptitude::UI::Pause-After-Download "true";
aptitude::Pkg-Display-Limit "";
aptitude::Delete-Unused-Pattern "";
aptitude::Delete-Unused "true";
aptitude::Suggests-Important "true";
aptitude::Recommends-Important "true";
aptitude::Auto-Fix-Broken "true";
aptitude::Auto-Install "true";
aptitude::Log "/var/log/aptitude";
aptitude::Warn-Not-Root "true";
aptitude::Forget-New-On-Install "false";
aptitude::Forget-New-On-Update "false";
aptitude::Display-Planned-Action "true";
aptitude::Changelog-URL-Template "http://cgi.debian.org/cgi-bin/get-changelog?package=%s";
aptitude::AutoClean-After-Update "false";
aptitude::Auto-Upgrade "true";

On Tue, May 07, 2002 at 12:10:38AM -0400, Faheem Mitha <email address hidden> was heard to say:
>
>
> On Sat, 4 May 2002, Daniel Burrows wrote:
>
> > On Sat, May 04, 2002 at 12:17:32AM -0400, Faheem Mitha <email address hidden> was heard to say:
> > > b) that if you put a package (say foo) on hold in the traditional way,
> > > # echo "foo hold" | dpkg --set-selections
> > > this is completely ignored by aptitude.
> >
> > Could you give me a reproducible test case? This has always worked
> > for me.
>
> That is strange. I get this behaviour with every package I tried. Ok, here
> is an example of a run (with vim).
>
> Chrestomanci:~# dpkg --get-selections | grep vim
> vim hold

  hm, it seems that this is broken for when you use the command-line; the
interactive UI picks it up just fine. Why this should be, I don't know;
it's probably a side effect of the way the command-line initializes the
backend (it doesn't select as many things automatically, so that things like
single-package installs work)

  Daniel

--
/-------------------- Daniel Burrows <email address hidden> -------------------\
| "But what *does* kill me bloody well leaves me dead!" |
| -- Terry Pratchett, _Carpe Jugulum_ |
\-- Does your computer have Super Cow Powers? ------- http://www.debian.org --/

On Tue, 7 May 2002, Daniel Burrows wrote:

> hm, it seems that this is broken for when you use the command-line; the
> interactive UI picks it up just fine. Why this should be, I don't know;
> it's probably a side effect of the way the command-line initializes the
> backend (it doesn't select as many things automatically, so that things like
> single-package installs work)

Unfortunately, I (and lots of other people I imagine) like to use the
command line. Should I file this as a separate bug (or not)? Thanks for
the clarification.

                                                         Faheem.

On Tue, May 07, 2002 at 04:53:24PM -0400, Faheem Mitha <email address hidden> was heard to say:
> On Tue, 7 May 2002, Daniel Burrows wrote:
>
> > hm, it seems that this is broken for when you use the command-line; the
> > interactive UI picks it up just fine. Why this should be, I don't know;
> > it's probably a side effect of the way the command-line initializes the
> > backend (it doesn't select as many things automatically, so that things like
> > single-package installs work)
>
> Unfortunately, I (and lots of other people I imagine) like to use the
> command line. Should I file this as a separate bug (or not)? Thanks for
> the clarification.

  Go ahead and file another bug, with a heading like
"aptitude loses dselect state in command-line mode". (you can probably
find a better title)

  It's a bug, but it's entirely different from what Joey was talking
about, it's probably easier to fix, and I'm more interested in fixing it.

  Daniel

--
/-------------------- Daniel Burrows <email address hidden> -------------------\
| Whoever fights monsters should see to it that in the |
| process he does not become a monster. And when you look |
| into an abyss, the abyss also looks into you. |
| -- Friedrich Nietzsche |
\------------- Debian GNU/Linux http://www.debian.org -- Because. ------------/

# aptitude uses its own state information
reassign 174091 aptitude
severity 174091 normal
merge 174091 137771

severity 171248 normal
retitle 171248 corrupted cache files cause segfault
merge 165448 171248

thanks

--
 - mdz

severity 161810 normal
merge 161810 137771
thanks

On Sat, Sep 21, 2002 at 08:53:34PM +0200, <email address hidden> was heard to say:
> Package: aptitude
> Version: 0.2.11.1-3
> Severity: wishlist
>
> I have installed several packages manualy, because I added a patch there, which
> is long outstanding on program's bugtrack, but was not applied yet. I have set
> the packages on hold using aptitude. But apt-get, dpkg nor dselect honor this
> seting. I think aptitude should set the hold flag globally, not just for it's
> internal use.
>
> -- System Information
> Debian Release: testing/unstable
> Kernel Version: Linux vagabond 2.4.19 #11 Po srp 5 12:31:27 CEST 2002 i686 unknown unknown GNU/Linux
>
> Versions of the packages aptitude depends on:
> ii libc6 2.2.5-14.3 GNU C Library: Shared libraries and Timezone
> ii libncurses5 5.2.20020112a- Shared libraries for terminal handling
> ii libsigc++0 1.0.4-3 Type-safe Signal Framework for C++ - runtime
> ii libstdc++2.10- 2.95.4-11 The GNU stdc++ library
> ii apt 0.5.4 Advanced front-end for dpkg
> ^^^ (Provides virtual package libapt-pkg-libc6.2-3-2-3.2)
>
>

--
/-------------------- Daniel Burrows <email address hidden> -------------------\
| "Oh my god! The entire map is written in GIBBERISH!" |
| "Worse, my friend. It's written in German!" -- Fluble |
\------- (if (not (understand-this)) (go-to http://www.schemers.org)) --------/

severity 277719 normal
merge 277719 137771 220794
thanks
--
/------------------- Daniel Burrows <email address hidden> ------------------\
| "It is said that someone at a party once asked |
| the famous philosopher Ly Tin Weedle, 'why |
| are you here?', and the reply took three years." |
| -- Terry Pratchett |
\---------------- The Turtle Moves! -- http://www.lspace.org ---------------/

When I make packages held back (I don't want to upgrade due to a bug in the newest version which makes it unusable) in aptitude, update-manager still wants to upgrade this package. Apt-get does the right thing though.

John Vivirito (gnomefreak) wrote :

Thank you for your bug report can you please attach the files in /var/log/dist-upgrade or give us the output of what you mean.

Changed in update-manager:
assignee: nobody → gnomefreak
status: Unconfirmed → Needs Info
Jonas Ådahl (jadahl) wrote :

[13:44]-[toxic@lap]-[~]$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
  erlang erlang-base
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.

Now the update-manager icon on the right top of the screen always is there.

apt-get dist-upgrade tries to install newer versions of these packages, but in aptitude when doing the "U g" keystrokes (U = Mark all upgradable packages to be upgraded, g = Perform all pending installations, removals, and upgrades.) it doesn't try to upgrade the 2 held back packages.

John Vivirito (gnomefreak) wrote :

Jadahl is this still an issue for you, if so can you please attach the files in /var/log/dist-upgrade.

Changed in update-manager:
assignee: gnomefreak → nobody
Jonas Ådahl (jadahl) wrote :

Yes, update-manager still always wants to upgrade erlang. Here are the content of /var/log/dist-upgrade

Daniel Hahler (blueyed) on 2007-04-30
Changed in update-manager:
status: Needs Info → Confirmed
kko (kko) wrote :

Unmarking as a duplicate. Reason: If I understand correctly, this issue is for Ubuntu (Gnome) and the other report (bug 72806) is for Kubuntu (KDE).

pauls (paulatgm) wrote :

Most likely the code in kubuntu is taken from ubuntu, so a fix here could lead to the fix there.

This goes back to 2006 Dapper. Yet it's importance or assignment have never been done. How does that happen on something as important as the updater? Also, it's probably easy to fix, since the adept manager itself does not have a problem. So, just copy that code to the updater.

# Automatically generated email from bts, devscripts version 2.10.11
forcemerge 137771 453702

package apticron
block 431869 by 137771
thanks

It is true that apticron doesn't use aptitude, but as long as I understand the
problem, this is still an aptitude bug. The question is the way you put
packages on hold. If you use aptitude for that (# aptitude hold foo), neither
apt nor dselect will consider it because it saves that information into an
internal database (see #137771). While if you do that by the traditional way
(# echo "foo hold" | dpkg --set-selections) it is considered by apt-get, and
also by apticron.

I'll block this bug, since it cannot be fixed before having #137771 fixed.

Regards,

--
Tássia Camões Araújo

forcemerge 137771 146207
forcemerge 137771 199887
thanks
hope this is right, just trying to help

I suppose aptitude uses a package state different than apt-get's? Lately, I seem to be addicted to using aptitude. But this bug here (about aptitude and dpkg)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=174091
is a bummer. Installing Synaptic or using "dpkg --set-selections" seems to be the current viable workaround.

Thanks for your report. Assigning to aptitude / triaged/ medium.

Thanks for your help and don't hesitate to submit any new bug.

Changed in update-manager:
importance: Undecided → Medium
status: Confirmed → Triaged
Changed in aptitude:
status: Unknown → New
Daniel Hahler (blueyed) on 2009-03-20
Changed in aptitude:
importance: Unknown → Undecided
importance: Undecided → Unknown
status: New → Unknown
Changed in aptitude:
status: Unknown → New
p2 (p2000000000) wrote :

ignoring on-hold packages by update-manager (update-notifier) is not aptitude or apt-get bug it's update-manager's bug!

dvo (mueller8) wrote :

Whichever package's bug it is, it's pretty annoying that the bug is around for several years already.
Experimenting with adept_notifier, I found out that it compares the available versions as given in any of the files /var/lib/apt/lists/* with the versions installed according to /var/lib/dpkg/status. My workaround is for each of the held packages to manipulate the "Version: " entry in /var/lib/dpkg/status i.e. replacing the version number with something *higher* than the available version.

G M (bugzilla-postpro) wrote :

This is still a problem in 10.04. I have kernel packages held back in aptitude and Update Manager attempts to upgrade them every time it runs, resulting in me having to click about 8 checkboxes. Worse, since there are dependencies, not clicking in the right order can cause Update Manager to re-check some of the checkboxes I've unchecked.

Is the "Held" function an aptitude, apt, or dpkg feature? Since
aptitude is not official, I would not expect other apt clients to obey it.

Considering comment #13 it's a feature of at least both apt and aptitude, however in apt it's called kept back, not held back.

jeroendv (fly-jdv) wrote :

how can we get this bug report to be considered as important/fixed?
what would be the correct procedure?
simply making this bugreport obviously didn't do it, since it's been around for years it seems and still hasn't been fixed.
the fact that it only affects 6 people, can only signify that not a lot of people have found there way to this page.

description: updated
summary: - Held back packages not ignored
+ Held back packages not ignored by update-manager

TRIAGED:
as mentioned earlier, if you use the the "dpkg --set-selections" method (see 7.12 at http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html) to put a package on hold, instead of the "aptitude hold <packageName>" command.
Then the update-manager will successfully ignore future upgrades for that package,
the update-notifier will also no longer warn about available upgrades for those packages that have been put on hold.

extra information:
it seems though that the concept of putting a package on hold in the dpkg-way is different from the aptitude way.
for example, after putting a package on hold using "dpgk --set-selections", I can then proceed to run "aptitude unhold"
after which aptitude will again try to upgrade the package when running "aptitude safe-upgrade".
however running "dpkg --get-selections" shows that the package is still marked as hold, and both "apt-get upgrade" and the update-manager are still ignoring it.

thus it seems that aptitude is at fault here for not playing nicely with the update-manager/dpkg/apt-get, which is kind of weird since aptitude is recommended as the preferred way to administer your system.

long story short, the bug as was posted is triaged,
but maybe a new bugreport should be posted regarding this anomalous behaviour of aptitude :-s

Rolf Leggewie (r0lf) wrote :

bug 185981 and bug 75332 look like dupes.

Changed in aptitude (Debian):
status: New → Confirmed
Daniel Hartwig (wigs) wrote :

No program is encouraged to interface with aptitude holds, these are very soon to be replaced by the universal dpkg holds.

Changed in update-manager:
status: New → Invalid
summary: - Held back packages not ignored by update-manager
+ aptitude has private package holds, should use dpkg
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.