aptitude has private package holds, should use dpkg

[Jonas Ådahl]

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.

[Daniel Burrows (dburrows)]

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

[Faheem Mitha (faheem-email)]

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

[Daniel Burrows (dburrows)]

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

[Faheem Mitha (faheem-email)]

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

[Daniel Burrows (dburrows)]

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

[Faheem Mitha (faheem-email)]

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.

[Daniel Burrows (dburrows)]

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

[Matt Zimmerman (mdz)]

# 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

[Daniel Burrows (dburrows)]

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

[Daniel Burrows (dburrows)]

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

[Jonas Ådahl (jadahl)]

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

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.

[Jonas Ådahl (jadahl)]

[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)]

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

[Jonas Ådahl (jadahl)]

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

[kko (kko)]

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

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.

[Daniel Burrows (dburrows)]

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

[=?UTF-8?Q?T=C3=A1ssia_Cam=C3=B5es_Ar?==?UTF-8?Q?a=C3=BAjo?= (debian-tassia)]

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

[jidanni (dan-jacobson)]

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

[Ahmad Syukri Abdollah (syockit)]

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.

[Jean-Baptiste Lallement (jibel)]

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

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

[p2 (p2000000000)]

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

[dvo (mueller8)]

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

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.

[Steve Romanow (slestak989)]

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.

[Jonas Ådahl (jadahl)]

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

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.

[jeroendv (fly-jdv)]

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

bug 185981 and bug 75332 look like dupes.

[Daniel Hartwig (wigs)]

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

[Rolf Leggewie (r0lf)]

Is this still an issue?

[Axel Beckert (xtaran)]

Hi,

Rolf Leggewie wrote:
> Is this still an issue?

Depends. If you consider https://bugs.debian.org/137771 (as linked to
and marked as "fix released") to be the Debian-equivalent of this bug
report, it's fixed since 0.7.2-1 from September 2015.

  Regards, Axel
--
 ,''`. | Axel Beckert <email address hidden>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
  `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE

[Rolf Leggewie (r0lf)]

Thanks, Axel.

Before I close this as fixed here in Launchpad, can I ask you to elaborate more on the "Depends" in your reply? How would you consider this still an active ticket? Is it maybe best to open a new ticket and reference this one to keep things easier to understand?

I'm just doing BTS maintenance.