Debian Bug report logs - #137771
aptitude: holds should take effect in /var/lib/dpkg/status as well

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: aptitude: holds should take effect in /var/lib/dpkg/status as well

Date: Sun, 10 Mar 2002 20:23:14 -0500

Package: aptitude
Version: 0.2.10-1
Severity: normal

aptitude's holds arn't very useful, since they are ignored by dselect
and apt both.

root@silk:/usr/doc/aptitude> aptitude hold telnet  
Reading Package Lists... Done
Building Dependency Tree       
Reading extended state information... Done
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0B of archives. After unpacking 0B will be used.
Writing extended state information... Done
Reading changelogs...Done
Reading Package Lists... Done             
Building Dependency Tree       
Reading extended state information... Done
root@silk:/usr/doc/aptitude> apt-get -s upgrade  
Reading Package Lists... Done
Building Dependency Tree... Done
1 packages upgraded, 0 newly installed, 0 to remove and 0  not upgraded.
Inst telnet (0.17-17 Debian:unstable)
Conf telnet (0.17-17 Debian:unstable)
root@silk:/home/joey> echo "telnet hold" | dpkg --set-selections
root@silk:/home/joey> apt-get -s upgrade 
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages have been kept back
  telnet 

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux silk 2.4.18 #1 Tue Feb 26 00:23:37 EST 2002 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 dpkg
ii  libc6                    2.2.5-3         GNU C Library: Shared libraries an
ii  libncurses5              5.2.20020112a-5 Shared libraries for terminal hand
ii  libsigc++0               1.0.4-2         Typesafe Signal Framework for C++ 
ii  libstdc++2.10-glibc2.2   1:2.95.4-3      The GNU stdc++ library

Message #10 received at 137771@bugs.debian.org (full text, mbox, reply):

From: Daniel Burrows <dburrows@debian.org>

To: 137771@bugs.debian.org, 137771-submitter@bugs.debian.org

Subject: fixed in CVS

Date: Sun, 24 Mar 2002 13:08:25 -0500

  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 <dburrows@debian.org> -------------------\
| "By Elbereth and Lúthien the fair, you shall have neither the Ring, nor me!" |
|   -- Frodo Baggins                                                           |
\---------------------- A duck! -- http://www.python.org ---------------------/

Message #18 received at 137771@bugs.debian.org (full text, mbox, reply):

From: Faheem Mitha <faheem@email.unc.edu>

To: Debian Bug Tracking System <137771@bugs.debian.org>

Subject: aptitude: followup on holds issues

Date: Sat, 04 May 2002 00:17:32 -0400

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 dpkg
ii  libc6                    2.2.5-4         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-7      The GNU stdc++ library

Message #23 received at 137771@bugs.debian.org (full text, mbox, reply):

From: Daniel Burrows <dburrows@debian.org>

To: Faheem Mitha <faheem@email.unc.edu>, 137771@bugs.debian.org

Subject: Re: Bug#137771: aptitude: followup on holds issues

Date: Sat, 4 May 2002 00:33:02 -0400

On Sat, May 04, 2002 at 12:17:32AM -0400, Faheem Mitha <faheem@email.unc.edu> 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 <dburrows@debian.org> -------------------\
|                        After the game, the king and                         |
|                        the pawn go in the same box.                         |
|                          -- Italian proverb                                 |
\---------------------- A duck! -- http://www.python.org ---------------------/

Message #28 received at 137771@bugs.debian.org (full text, mbox, reply):

From: Faheem Mitha <faheem@email.unc.edu>

To: 137771@bugs.debian.org

Subject: Re: Bug#137771: aptitude: followup on holds issues

Date: Tue, 7 May 2002 00:10:38 -0400 (EDT)

On Sat, 4 May 2002, Daniel Burrows wrote:

> On Sat, May 04, 2002 at 12:17:32AM -0400, Faheem Mitha <faheem@email.unc.edu> 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";

Message #33 received at 137771@bugs.debian.org (full text, mbox, reply):

From: Daniel Burrows <dburrows@debian.org>

To: Faheem Mitha <faheem@email.unc.edu>, 137771@bugs.debian.org

Subject: Re: Bug#137771: aptitude: followup on holds issues

Date: Tue, 7 May 2002 16:23:31 -0400

On Tue, May 07, 2002 at 12:10:38AM -0400, Faheem Mitha <faheem@email.unc.edu> was heard to say:
> 
> 
> On Sat, 4 May 2002, Daniel Burrows wrote:
> 
> > On Sat, May 04, 2002 at 12:17:32AM -0400, Faheem Mitha <faheem@email.unc.edu> 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 <dburrows@debian.org> -------------------\
|            "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 --/

Message #38 received at 137771@bugs.debian.org (full text, mbox, reply):

From: Faheem Mitha <faheem@email.unc.edu>

To: 137771@bugs.debian.org

Subject: Re: Bug#137771: aptitude: followup on holds issues

Date: Tue, 7 May 2002 16:53:24 -0400 (EDT)

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.

Message #43 received at 137771@bugs.debian.org (full text, mbox, reply):

From: Daniel Burrows <dburrows@debian.org>

To: Faheem Mitha <faheem@email.unc.edu>, 137771@bugs.debian.org

Subject: Re: Bug#137771: aptitude: followup on holds issues

Date: Tue, 7 May 2002 17:52:49 -0400

On Tue, May 07, 2002 at 04:53:24PM -0400, Faheem Mitha <faheem@email.unc.edu> 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 <dburrows@debian.org> -------------------\
|          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. ------------/

Message #70 received at 137771@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: 137771@bugs.debian.org

Cc: 328616@bugs.debian.org

Subject: [Aptitude-devel] #137771: aptitude's vs dpkg's hold state (was: Processed: more bts etc.)

Date: Thu, 4 Oct 2012 17:03:16 +0200

Hi Daniel(*),

Debian Bug Tracking System wrote on 15th of September 2012:
> Processing commands for control@bugs.debian.org:
> 
> > tags 137771 + help
> Bug #137771 [aptitude] aptitude: holds should take effect in /var/lib/dpkg/status as well
> Bug #146207 [aptitude] aptitude: in command-line mode ignores hold set by dpkg --set-selections
> Bug #161810 [aptitude] aptitude: Aptitude does not set hold state
> Bug #174091 [aptitude] apt-get ignores hold set with aptitude
> Bug #199887 [aptitude] Subject: packages held by dselect are not detected in aptitude
> Bug #220794 [aptitude] aptitude: can not set package to hold
> Bug #277719 [aptitude] hold in aptitude and in dpkg are not the same
> Bug #328616 [aptitude] Add "revision" information to the dpkg database?
> Bug #453702 [aptitude] sudo aptitude hold packageName does not modify selections
> Added tag(s) help.

This is a quite old bug and not only according to the amount of
duplicates an annoying one. ;-)

It's likely less trivial than it seems, otherwise it would have been
fixed already a long time ago.

I'm though curious what's the culprit which -- for more than a decade
-- kept developers from fixing it.

I browsed through the merged bugs, but the only hint I found so far
about the issue described in http://bugs.debian.org/137771 is in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=220794#20:

"the databases do not contain exactly equivalent information, and
there is no one-to-one translation between them" (But it's not
mentioned what the differences actually are.)

So I would be happy if you could post some more details to #137771
about where you could need or would like to have help. Do you think
it's rather a technical or a conceptual issue?

TIA!

(*) JFTR: Daniel Hartwig, not Daniel Burrows. :-)

P.S.: http://bugs.debian.org/328616 looks to me like a different issue
than http://bugs.debian.org/137771 -- maybe related, but not
specifically related to syncing hold states.

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

Message #75 received at 137771@bugs.debian.org (full text, mbox, reply):

From: Daniel Hartwig <mandyke@gmail.com>

To: Axel Beckert <abe@debian.org>, 137771@bugs.debian.org

Cc: 328616@bugs.debian.org

Subject: Re: Bug#137771: #137771: aptitude's vs dpkg's hold state (was: Processed: more bts etc.)

Date: Fri, 5 Oct 2012 10:44:53 +0800

Hi Axel, others

This is one of the major issues remaining in aptitude.  A task I will
eventually get to when schedule permits.

I have tagged it “help” for the obvious reasons of drawing much-needed
(developer) attention to it.  It is not expected to be particularly
hard though it will certainly take a considerable commitment and
effort to resolve.  It does not require extensive knowledge of
aptitude either, only some knowledge of APT and a certain enthusiasm.

I have also started a bounty [1] for the issue which is held in trust,
claimable by any person who submits a patch that fixes it.  This is a
nice way for non-developers to contribute some support to this task.

[1] http://www.fossfactory.org/project/p317

On 4 October 2012 23:03, Axel Beckert <abe@debian.org> wrote:
> It's likely less trivial than it seems, otherwise it would have been
> fixed already a long time ago.
>
> I'm though curious what's the culprit which -- for more than a decade
> -- kept developers from fixing it.

Basically there are two kinds of package holds:
- dselect, stored in /var/lib/dpkg/status; and
- aptitude, stored in /var/lib/aptitude/pkgstates.

When aptitude starts it attempts to divine which dselect holds have
changed and updates its database accordingly (not perfect).  At no
point does aptitude update the dselect holds when it's own have
changed.  APT only knows about dselect holds, which is why we see
reports like “$APT_FRONTEND does not respect aptitude holds” and the
inverse of that.

The reason for the aptitude holds appear mostly historical: this was
not a well integrated aspect of early APT, it appears that it was
easier to implement holds directly in aptitude.  To this day the
dselect holds are not fully integrated in to APT (for example,
“apt-mark hold” invokes dpkg directly rather than using class DPkgPM).

> I browsed through the merged bugs, but the only hint I found so far
> about the issue described in http://bugs.debian.org/137771 is in
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=220794#20:
>
> "the databases do not contain exactly equivalent information, and
> there is no one-to-one translation between them" (But it's not
> mentioned what the differences actually are.)

I have seen this comment (quite old) but not investigated its claim
yet.  I *suspect* that it no longer applies and was originally to do
with MarkInstall, etc. not respecting dselect holds, or something
similar.

Burrows submitted functionality to APT [2] to support this which has
been applied for some time and now APT does now respect the dselect
holds.  This cleaned up a lot of the issues users were expecting, but
the greater problem of aptitude holds not being respected by other
tools remains.

[2] http://bugs.debian.org/470035

> So I would be happy if you could post some more details to #137771
> about where you could need or would like to have help. Do you think
> it's rather a technical or a conceptual issue?

At this point I think that the reasons which gave rise to aptitude
holds have mostly disappeared.  Though I have not determined yet
precisely what they were or whether any remain, I think the best move
going forward is to simple drop the concept of an aptitude hold and
completely integrate the dselect-/APT-style used by all other
frontends.

This is a task for programmers who are a little familiar with APT.
Aptitude needs to be adjusted to read hold states from
PkgIterator->SelectedState, write hold states using dpkg (refer to
apt-mark.cc), and migrate it's internal hold states to
/var/lib/dpkg/status.

Alternatively, libapt-pkg's DPkgPM and also pkgPackageManager classes
could be updated to support changing hold state first, then aptitude
updated to write hold states using that.  I am not actually sure
whether this is lacking currently or not.

Developers, to get started stick your faces in to:
- aptitude/src/generic/apt/aptcache.cc;
- apt/apt-pkg/depcache.h;
- apt/apt-pkg/packagemanager.h;
- apt/apt-pkg/deb/dpkgpm.h; and
- apt/cmdline/apt-mark.cc (to see how it should be done).

An extensive knowledge of aptitude is *not* required :-)

> P.S.: http://bugs.debian.org/328616 looks to me like a different issue
> than http://bugs.debian.org/137771 -- maybe related, but not
> specifically related to syncing hold states.

Ah, you are correct.  #328616 is more related to the “aptitude
installs (removes) package removed (installed) by apt-get, etc.”  The
hold-bugs are currently entangled as blocking an archived bug.  I have
been preparing some more BTS maintenance on them to fix that and merge
some others so I'll unmerge this one at the same time.

Regards

Message #80 received at 137771@bugs.debian.org (full text, mbox, reply):

From: Daniel Hartwig <mandyke@gmail.com>

To: Axel Beckert <abe@debian.org>, 137771@bugs.debian.org

Subject: Re: Bug#137771: #137771: aptitude's vs dpkg's hold state (was: Processed: more bts etc.)

Date: Fri, 5 Oct 2012 10:56:22 +0800

On 5 October 2012 10:44, Daniel Hartwig <mandyke@gmail.com> wrote:
>> I browsed through the merged bugs, but the only hint I found so far
>> about the issue described in http://bugs.debian.org/137771 is in
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=220794#20:
>>
>> "the databases do not contain exactly equivalent information, and
>> there is no one-to-one translation between them" (But it's not
>> mentioned what the differences actually are.)
>
> I have seen this comment (quite old) but not investigated its claim
> yet.  I *suspect* that it no longer applies and was originally to do
> with MarkInstall, etc. not respecting dselect holds, or something
> similar.
>
> Burrows submitted functionality to APT [2] to support this which has
> been applied for some time and now APT does now respect the dselect
> holds.  This cleaned up a lot of the issues users were expecting, but
> the greater problem of aptitude holds not being respected by other
> tools remains.
>
> [2] http://bugs.debian.org/470035

Something that anyone could do is to investigate this comment by
Burrows and/or determine if there is any conceptual difference between
the intentions of the current “aptitude hold” and “apt-mark hold”.
Both seem to be about preventing a package from being upgraded or
removed (etc.) by actions such as dist-upgrade, or installing/removing
another package, but is there anything extra intended by “aptitude
hold” which is not covered by “apt-mark hold”?

Take a look at the documentation for each, maybe have a poke around
the code, and see what the implications are.

The results of such an investigation will make it much easier for
developers to move forward on this.

Regards

Message #85 received at 137771@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: 137771@bugs.debian.org

Subject: Re: Bug#137771: aptitude's vs dpkg's hold state

Date: Fri, 5 Oct 2012 12:06:18 +0200

Hi Daniel,

thanks for your reply. It definitely brings light into the issue!

Daniel Hartwig wrote:
> Basically there are two kinds of package holds:
> - dselect, stored in /var/lib/dpkg/status; and
> - aptitude, stored in /var/lib/aptitude/pkgstates.

Hmm. While you definitely can set and query holds without dselect
being installed, I wonder if dpkg works any different with them. At
least when I stumbled upon it, dpkg seems to let aptitude
happily override dpkg's hold, despite dpkg's man-page says:

       hold   A package marked to be on hold is not handled by dpkg,
       	      unless forced to do that with option --force-hold.

> When aptitude starts it attempts to divine which dselect holds have
> changed and updates its database accordingly (not perfect). At no
> point does aptitude update the dselect holds when it's own have
> changed.

Real life confirms that:

Thanks to tons of iceweasel versions on mozilla.debian.net, I played
around a little bit (on Squeeze) with downgrading, upgrading and
holding packages and then doing it again. ;-)

# dpkg --get-selections | fgrep iceweasel; dpkg-query -l iceweasel | egrep '^[ih]'; aptitude search '^iceweasel$'
iceweasel                                       install
ii  iceweasel      16.0~b6-1~bpo6 Web browser based on Firefox
i A iceweasel                   - Web browser based on Firefox
# echo iceweasel hold | dpkg --set-selections
# dpkg --get-selections | fgrep iceweasel; dpkg-query -l iceweasel | egrep '^[ih]'; aptitude search '^iceweasel$'
iceweasel                                       hold
hi  iceweasel      16.0~b6-1~bpo6 Web browser based on Firefox
ihA iceweasel                   - Web browser based on Firefox
# echo iceweasel install | dpkg --set-selections
# dpkg --get-selections | fgrep iceweasel; dpkg-query -l iceweasel | egrep '^[ih]'; aptitude search '^iceweasel$'
iceweasel                                       install
ii  iceweasel      16.0~b6-1~bpo6 Web browser based on Firefox
i A iceweasel                   - Web browser based on Firefox                                                    

dpkg's holds are handled like hold flags set by aptitude -- but only
until I change something in aptitude. From there on it ignores dpkg's
hold flag:

# dpkg --get-selections | fgrep iceweasel; dpkg-query -l iceweasel | egrep '^[ih]'; aptitude search '^iceweasel$'
iceweasel                                       install
ii  iceweasel      15.0.1-1~bpo60 Web browser based on Firefox
i A iceweasel                   - Web browser based on Firefox
# echo iceweasel hold | dpkg --set-selections
# dpkg --get-selections | fgrep iceweasel; dpkg-query -l iceweasel | egrep '^[ih]'; aptitude search '^iceweasel$'
iceweasel                                       hold
hi  iceweasel      15.0.1-1~bpo60 Web browser based on Firefox
ihA iceweasel                   - Web browser based on Firefox
# aptitude full-upgrade
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
# aptitude unhold iceweasel
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
# dpkg --get-selections | fgrep iceweasel; dpkg-query -l iceweasel | egrep '^[ih]'; aptitude search '^iceweasel$'
iceweasel                                       hold
hi  iceweasel      15.0.1-1~bpo60 Web browser based on Firefox
i A iceweasel                   - Web browser based on Firefox
# aptitude safe-upgrade
The following packages will be upgraded: 
  iceweasel 
1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,067 kB of archives. After unpacking 379 kB will be used.
Do you want to continue? [Y/n/?] 
Get:1 http://mozilla.debian.net/ squeeze-backports/iceweasel-beta iceweasel amd64 16.0~b6-1~bpo60+1 [2,067 kB]
Fetched 2,067 kB in 0s (4,688 kB/s)
(Reading database ... 486708 files and directories currently installed.)
Preparing to replace iceweasel 15.0.1-1~bpo60+1 (using .../iceweasel_16.0~b6-1~bpo60+1_amd64.deb) ...
Leaving 'diversion of /usr/bin/firefox to /usr/bin/firefox.real by iceweasel'
Unpacking replacement iceweasel ...
Processing triggers for gnome-menus ...
Processing triggers for desktop-file-utils ...
Processing triggers for man-db ...
Processing triggers for hicolor-icon-theme ...
Processing triggers for menu ...
Setting up iceweasel (16.0~b6-1~bpo60+1) ...
Installing new version of config file /etc/iceweasel/searchplugins/locale/en-US/twitter.xml ...
Processing triggers for menu ...
                                         
Current status: 0 updates [-1].
# dpkg --get-selections | fgrep iceweasel; dpkg-query -l iceweasel | egrep '^[ih]'; aptitude search '^iceweasel$'
iceweasel                                       hold
hi  iceweasel      16.0~b6-1~bpo6 Web browser based on Firefox
i A iceweasel                   - Web browser based on Firefox
#

Either dpkg doesn't complain about having its holds overridden,
aptitude suppresses dpkg's complaints or aptitude passes options to
dpkg to not complain, i.e. --force-hold.

> > So I would be happy if you could post some more details to #137771
> > about where you could need or would like to have help. Do you think
> > it's rather a technical or a conceptual issue?
> 
> At this point I think that the reasons which gave rise to aptitude
> holds have mostly disappeared.  Though I have not determined yet
> precisely what they were or whether any remain, I think the best move
> going forward is to simple drop the concept of an aptitude hold and
> completely integrate the dselect-/APT-style used by all other
> frontends.

As long as you can still set holds via aptitude using "=" (as
keybinding as well as package suffix on the commandline), that sounds
fine and the right way for me -- mostly because I don't see any
conceptual differences from the user point of view, except that it
will cause fewer bug-reports in the long run. ;-)

> An extensive knowledge of aptitude is *not* required :-)

:-)

> > P.S.: http://bugs.debian.org/328616 looks to me like a different issue
> > than http://bugs.debian.org/137771 -- maybe related, but not
> > specifically related to syncing hold states.
> 
> Ah, you are correct.  #328616 is more related to the “aptitude
> installs (removes) package removed (installed) by apt-get, etc.”  The
> hold-bugs are currently entangled as blocking an archived bug.  I have
> been preparing some more BTS maintenance on them to fix that and merge
> some others so I'll unmerge this one at the same time.

Great, thanks!

And thanks again for the insight.

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

Message #90 received at 137771@bugs.debian.org (full text, mbox, reply):

From: Daniel Hartwig <mandyke@gmail.com>

To: Axel Beckert <abe@debian.org>, 137771@bugs.debian.org

Subject: Re: Bug#137771: aptitude's vs dpkg's hold state

Date: Fri, 5 Oct 2012 19:28:34 +0800

On 5 October 2012 18:06, Axel Beckert <abe@debian.org> wrote:
> dpkg's holds are handled like hold flags set by aptitude -- but only
> until I change something in aptitude. From there on it ignores dpkg's
> hold flag:

Yes.  Once aptitude considers it's own hold more up-to-date it will
happily ignore anything from the dpkg database.  This is actually
correct (!) for the current situation, since aptitude's direct
instruction to (un)hold is more recent than the information in dpkg.

From some of the reports this process seems to break down when a dpkg
hold is overridden in aptitude, then later the package status is
changed outside of aptitude again (such as maybe dpkg unhold again, or
install/upgrade).  By migrating aptitude to use only the dpkg holds we
will avoid this problem.

> Either dpkg doesn't complain about having its holds overridden,
> aptitude suppresses dpkg's complaints or aptitude passes options to
> dpkg to not complain, i.e. --force-hold.

The later, though it is libapt-pkg which arranges for dpkg to not complain.

Internally, APT considers the dpkg holds (in MarkInstall and friends)
before it asks dpkg to do anything.  It then arranges for dpkg to
ignore any holds, since they are already considered.  Aptitude
considers it's own holds to be more up-to-date than the dpkg ones, so
it instructs APT to not even consider those.

This is also mostly correct given the current situation.

>> At this point I think that the reasons which gave rise to aptitude
>> holds have mostly disappeared.  Though I have not determined yet
>> precisely what they were or whether any remain, I think the best move
>> going forward is to simple drop the concept of an aptitude hold and
>> completely integrate the dselect-/APT-style used by all other
>> frontends.
>
> As long as you can still set holds via aptitude using "=" (as
> keybinding as well as package suffix on the commandline),

Indeed, I don't see any need to change the interface, just the
mechanism.  A hold is still a hold, and now one hold shall rule them
all.

> that sounds
> fine and the right way for me -- mostly because I don't see any
> conceptual differences from the user point of view, except that it
> will cause fewer bug-reports in the long run. ;-)

I don't see any difference either, but haven't looked enough at the
history or code to be 100% on that.  There is also Burrows' comment
which is not to be dismissed lightly; it is clear from his other
contributions that he was rather informed about APT and dpkg internals
at the time.

Message #121 received at 137771@bugs.debian.org (full text, mbox, reply):

From: "Manuel A. Fernandez Montecelo" <manuel.montezelo@gmail.com>

To: Joey Hess <joeyh@debian.org>, 137771@bugs.debian.org

Subject: Re: aptitude: holds should take effect in /var/lib/dpkg/status as well

Date: Wed, 16 Sep 2015 23:29:04 +0100

Control: tags -1 + pending


Hi Joey,

2002-03-11 01:23 Joey Hess:
>Package: aptitude
>Version: 0.2.10-1
>Severity: normal
>
>aptitude's holds arn't very useful, since they are ignored by dselect
>and apt both.

I committed a change so aptitude will now set selections back to dpkg.

dselect should use this information (although I don't know if you are
still using it after all of these years), and apt should have at least
"holds" into account -- I don't think that it honours other states
(e.g. pending installs/removes/purges).


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>

Message #130 received at 137771-close@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: 137771-close@bugs.debian.org

Subject: Bug#137771: fixed in aptitude 0.7.2-1

Date: Sat, 19 Sep 2015 16:34:07 +0000

Source: aptitude
Source-Version: 0.7.2-1

We believe that the bug you reported is fixed in the latest version of
aptitude, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 137771@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Axel Beckert <abe@debian.org> (supplier of updated aptitude package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Fri, 18 Sep 2015 00:42:40 +0200
Source: aptitude
Binary: aptitude aptitude-common aptitude-dbg aptitude-doc-cs aptitude-doc-en aptitude-doc-es aptitude-doc-fi aptitude-doc-fr aptitude-doc-it aptitude-doc-ja aptitude-doc-ru
Architecture: source all
Version: 0.7.2-1
Distribution: unstable
Urgency: medium
Maintainer: Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>
Changed-By: Axel Beckert <abe@debian.org>
Description:
 aptitude   - terminal-based package manager
 aptitude-common - architecture independent files for the aptitude package manager
 aptitude-dbg - Debug symbols for the aptitude package manager
 aptitude-doc-cs - Czech manual for aptitude, a terminal-based package manager
 aptitude-doc-en - English manual for aptitude, a terminal-based package manager
 aptitude-doc-es - Spanish manual for aptitude, a terminal-based package manager
 aptitude-doc-fi - Finnish manual for aptitude, a terminal-based package manager
 aptitude-doc-fr - French manual for aptitude, a terminal-based package manager
 aptitude-doc-it - Italian manual for aptitude, a terminal-based package manager
 aptitude-doc-ja - Japanese manual for aptitude, a terminal-based package manager
 aptitude-doc-ru - Russian manual for aptitude, a terminal-based package manager
Closes: 137771 222585 328616 434352 458351 493322 497206 498240 558352 584510 607118 769428 790568 798286 798485
Changes:
 aptitude (0.7.2-1) unstable; urgency=medium
 .
   * New upstream release. Please see /usr/share/aptitude/NEWS for a change
     log with more details.
 .
     - New features:
       * 'Escape' key cancels input dialogs (search, limit, etc.) (Closes:
         #493322)
       * Extend "firstchar" grouping policy to optionally use source
         package names.
       * [curses] Add 'New Source Package View' to Views menu (thanks
         Thadeu Lima de Souza Cascardo, really closes: #497206), with some
         updates and minor modifications, like more complex grouping.
       * [curses] Use Yellow/Brown colour to highlight downgrades (Closes:
         #584510)
       * Log file now contains version information for most actions
         (Closes: #222585)
       * Save selection state of packages to dpkg database (Closes:
         #137771)
       * Consider packages "unknown" to dpkg as not to install. (Closes:
         #328616) The behaviour of scheduled aptitude actions will be
         preserved.
 .
     - Bug fixes:
       * Disable strings gathered for translation (Closes: #790568)
       * Change to try to make updated status stats more clear (Closes:
         #458351)
       * [cmdline] Correctly print when a package should be purged (Closes:
         #798286)
       * [curses] With the option of mini-buffer prompts enabled,
         cancellation of the "Quit confirmation" with 'Escape' or 'Ctrl-g'
         does not cause the dialog/prompt to stop working (Closes: #607118)
       * [cmdline] Warn when package cannot be marked/unmarked auto
         (Closes: #498240)
       * Install signal handlers and do clean-up when terminating abruptly
         (Closes: #558352)
       * [curses] Set better ordering for groups of Preview Actions
         (Closes: #434352)
 .
     - User visible changes:
       * Change error string of source_policy_parser to be the same as the
         rest.
       * [curses] Improve titles and descriptions of views.
 .
     - Internal changes:
       * Improve retrieval of source package information with (upcoming)
         APT 1.1. Thanks to David Kalnischkies for the suggestion and
         implementation advice.
       * New helper dpkg_selections.{h,cc}, to help to manage saving
         selections to the dpkg database (--set-selections)
 .
     - Documentation:
       * Guide/User's Manual: Remove grouping policy "hier" from
         doc/??/aptitude.xml (the categorial/hierarchical browser features
         were removed in version 0.7)
 .
     - Translation updates:
       * Russian by Lev Lamberov (Closes: #798485, #769428)
 .
   * Add lintian override for spelling-error-in-binary "ressize", seems to
     be from "resource size" or such. Cannot be found in the source code.
   * Fix spelling errors in the two previous changelog entries as reported
     by Lintian.
   * Add lintian override for symlink to /usr/share/common-license/…
   * Remove explicit build-dependency on g++ >= 4:5.2, no more needed.
   * Detabify previous changelog entry.
   * Remove no more active team members from Uploaders as suggested by the
     MIA team. Every team member is welcome to re-add himself to Uploaders
     once he's active again. Thanks for all your work, Daniel and Daniel!
Checksums-Sha1:
 b8a535a5dabc91bead9d9d39c62df21a445c6e18 2952 aptitude_0.7.2-1.dsc
 d491aeaeab03ce2fa061104ab04bdcf0afa48575 4480344 aptitude_0.7.2.orig.tar.xz
 e24173e50a3acd3cfb2e0b6f3377d3bec6e84af5 44100 aptitude_0.7.2-1.debian.tar.xz
 644dc9c90fa718ca50f009460b6a6320af09a396 1515218 aptitude-common_0.7.2-1_all.deb
 cd72f7cc3a9f08445a2fcf2ded2abb25704da1d9 357394 aptitude-doc-cs_0.7.2-1_all.deb
 9854b1b65646f96bb59f8d845f20e48943f057c5 423660 aptitude-doc-en_0.7.2-1_all.deb
 c0d30d8432c402f3e6291b7c5d67192dfd8d3a03 401848 aptitude-doc-es_0.7.2-1_all.deb
 8b9c64606a21bb9f302b4124854d5fa3b610a2bd 264342 aptitude-doc-fi_0.7.2-1_all.deb
 2dbdd9a8993da1b2797fa3d3c5a82fda1a55fa5c 303866 aptitude-doc-fr_0.7.2-1_all.deb
 feb8a3a69ef48b5e0f3a34aafe86ced405b12ba6 264924 aptitude-doc-it_0.7.2-1_all.deb
 71ad0f2f87909096958df1fec1240a2ccab0d59c 360568 aptitude-doc-ja_0.7.2-1_all.deb
 6bdd39af724977280e5d59d09ad8e51f21687f7a 379834 aptitude-doc-ru_0.7.2-1_all.deb
Checksums-Sha256:
 5fed6f015ace9ae959df516e9e010975bbe4d5d8c6a2e8fa62b379e5aa76fcea 2952 aptitude_0.7.2-1.dsc
 0840f5897ca83db312424b26ca3b7094fe4acf928e3423dd9919fea3fa9e1d29 4480344 aptitude_0.7.2.orig.tar.xz
 8f1db336d950270c6855af7767e64b339cca590218a432b39ac70d8904d29fff 44100 aptitude_0.7.2-1.debian.tar.xz
 0cdbe9c05f14184ca3c5af16f3eb95f35f42e607552996c1a2a5ec67a2fc928c 1515218 aptitude-common_0.7.2-1_all.deb
 26cb5b901ed9f877fdc45244406dd0cf0c79dcdfcc6e3091d5b64089ee1ba4a3 357394 aptitude-doc-cs_0.7.2-1_all.deb
 f346fa8e8b5cbab976c7fb5b3f00a4c8d5ebe17346d490ab35a0685fb7af76db 423660 aptitude-doc-en_0.7.2-1_all.deb
 5e66d555e57abeff85818ef8473d2e05aece93f3d7d65f1d347b29f4ebd12c07 401848 aptitude-doc-es_0.7.2-1_all.deb
 edf3da3a190387870b8813b051237053a8a790de320648c915a94cad3a8ba07b 264342 aptitude-doc-fi_0.7.2-1_all.deb
 3db750bc38ab71a438bd94f15fa563bf961135919c887beea3712fd749a88fb4 303866 aptitude-doc-fr_0.7.2-1_all.deb
 5cd5f5300b482539f31aea162f8a2bc6959d6a764e78ba3dc660aaea4c78c543 264924 aptitude-doc-it_0.7.2-1_all.deb
 39f21d2d939ee834048a3198e3e6838fdf777471988aa483316707a634118cf2 360568 aptitude-doc-ja_0.7.2-1_all.deb
 775a3035fca43ab6387c4010484fb735b3b6aacde826b1999dfbd81a1ac8c44d 379834 aptitude-doc-ru_0.7.2-1_all.deb
Files:
 660e8fe0592f3e8dc300f6d242d53d12 2952 admin important aptitude_0.7.2-1.dsc
 b5d128727c0463028023043b107b344d 4480344 admin important aptitude_0.7.2.orig.tar.xz
 1bb36aa9dbb133627ef2b72ca48e2efe 44100 admin important aptitude_0.7.2-1.debian.tar.xz
 e1adf63f95e800b2b69fb1e1d27f6751 1515218 admin important aptitude-common_0.7.2-1_all.deb
 5a50d1adc708e174e607e4f2e4577f44 357394 doc optional aptitude-doc-cs_0.7.2-1_all.deb
 4b8b7d8e59e3269b671c24420a00749c 423660 doc optional aptitude-doc-en_0.7.2-1_all.deb
 86df1da211db2b91753f0a9c953c7516 401848 doc optional aptitude-doc-es_0.7.2-1_all.deb
 47d133dc8d6affafc5b9bdc31fd87469 264342 doc optional aptitude-doc-fi_0.7.2-1_all.deb
 fc327a34aa2f5320993784c4f0c3c6fb 303866 doc optional aptitude-doc-fr_0.7.2-1_all.deb
 e17889c34df7d3f85f70727b12c671ca 264924 doc optional aptitude-doc-it_0.7.2-1_all.deb
 b68c423d277fc53af8a9e475fb5066c9 360568 doc optional aptitude-doc-ja_0.7.2-1_all.deb
 f062bed7f6916028950ec1746d9e24b5 379834 doc optional aptitude-doc-ru_0.7.2-1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJV/YbgAAoJEGvmY8daNcl1ZT4P/RxpZxkKxDTVyH/oxR4YXPpz
+IqRuOCF4yihRR/RyexvUHLulEdT2KmnvuMJvTK6l12lzDJwsYMhpuNaCDHZAAx0
xT23/IdhJfeYM8+Z15bDNCECSxTlLfL5cRwC7RgTU5tRAja+kkjnwHtfW1Np/jgl
yOGOg6qipGZ15zRvcdiBwqw29Kgb5cNK907/Xe3/rgg8UsDqvpBCfL+QwIEwOrF1
YTTbQ44N8IjZUtTavRp/f2lrthvndlVjTSdIiMEoY1j2rJDZmDWw/H67uBoEmpfW
CJ5cUpvYjNxFhpXVZ3yGYyI1BqtrueyKhVermqHeTLEY/oe9Sa1BBIwaFZYSCNeZ
S5Y33PpxKNprBua4aPkfb9ipT9XVZ2EKRgAxCVxP7lFhUe0wTLopjuFE+YJW+CSx
DnHLSpDdfeFY801uTxpxkvJ/lwrG7VOrRNDKDLgna2yq4zZe7AICJlwJCM00/bXC
4LX75ueaqg9UWWL64LFWuPDibaiDhQqN2oe8Z/rA9LTUjCP2+aikqQheEPrR9U3h
xHI/GFZHUmoHrbRl3MEylVk8xIfI5ZSEhe/MPosc9yIwpMO4CIkPYEY0p1ERvB7M
w+fC9E2YSb8fWWfF+r8FFB5rqictL6MLwb6B/nFzSwKxy6o+snS12rUpx3P+yDPY
VwsQdbTgFTZOT7J9UxWy
=juGv
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.