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

version graph

Package: aptitude; Maintainer for aptitude is Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>; Source for aptitude is src:aptitude.

Reported by: Joey Hess <joeyh@debian.org>

Date: Mon, 11 Mar 2002 01:33:02 UTC

Severity: important

Tags: confirmed, help

Merged with 146207, 161810, 174091, 199887, 220794, 277719, 453702, 532189, 683099, 692017, 729761

Found in versions 0.2.11.1-3, aptitude/0.4.11.11-1, aptitude/0.6.8-1, aptitude/0.6.4-1.2, 0.2.10-1, aptitude/0.4.4-4, aptitude/0.6.8.1-2, aptitude/0.2.15.8-1, 0.2.11.1-2, 0.2.13-2, aptitude/0.2.15.9-6, 0.2.13-1

Blocking fix for 706770: keep/hold packages uninstalled

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Daniel Burrows <dburrows@debian.org>, aptitude@packages.qa.debian.org:
Bug#137771; Package aptitude. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
New Bug report received and forwarded. Copy sent to Daniel Burrows <dburrows@debian.org>, aptitude@packages.qa.debian.org. Full text and rfc822 format available.

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

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




Information forwarded to debian-bugs-dist@lists.debian.org, aptitude@packages.qa.debian.org:
Bug#137771; Package aptitude. Full text and rfc822 format available.

Acknowledgement sent to Daniel Burrows <dburrows@debian.org>:
Extra info received and forwarded to list. Copy sent to aptitude@packages.qa.debian.org. Full text and rfc822 format available.

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

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 sent on to Joey Hess <joeyh@debian.org>:
Bug#137771. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Burrows <dburrows@debian.org>, aptitude@packages.qa.debian.org:
Bug#137771; Package aptitude. Full text and rfc822 format available.

Acknowledgement sent to Faheem Mitha <faheem@email.unc.edu>:
Extra info received and forwarded to list. Copy sent to Daniel Burrows <dburrows@debian.org>, aptitude@packages.qa.debian.org. Full text and rfc822 format available.

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

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




Information forwarded to debian-bugs-dist@lists.debian.org, aptitude@packages.qa.debian.org:
Bug#137771; Package aptitude. Full text and rfc822 format available.

Acknowledgement sent to Daniel Burrows <dburrows@debian.org>:
Extra info received and forwarded to list. Copy sent to aptitude@packages.qa.debian.org. Full text and rfc822 format available.

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

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



Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Burrows <dburrows@debian.org>, aptitude@packages.qa.debian.org:
Bug#137771; Package aptitude. Full text and rfc822 format available.

Acknowledgement sent to Faheem Mitha <faheem@email.unc.edu>:
Extra info received and forwarded to list. Copy sent to Daniel Burrows <dburrows@debian.org>, aptitude@packages.qa.debian.org. Full text and rfc822 format available.

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

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





Information forwarded to debian-bugs-dist@lists.debian.org, aptitude@packages.qa.debian.org:
Bug#137771; Package aptitude. Full text and rfc822 format available.

Acknowledgement sent to Daniel Burrows <dburrows@debian.org>:
Extra info received and forwarded to list. Copy sent to aptitude@packages.qa.debian.org. Full text and rfc822 format available.

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

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



Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Burrows <dburrows@debian.org>, aptitude@packages.qa.debian.org:
Bug#137771; Package aptitude. Full text and rfc822 format available.

Acknowledgement sent to Faheem Mitha <faheem@email.unc.edu>:
Extra info received and forwarded to list. Copy sent to Daniel Burrows <dburrows@debian.org>, aptitude@packages.qa.debian.org. Full text and rfc822 format available.

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

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.




Information forwarded to debian-bugs-dist@lists.debian.org, aptitude@packages.qa.debian.org:
Bug#137771; Package aptitude. Full text and rfc822 format available.

Acknowledgement sent to Daniel Burrows <dburrows@debian.org>:
Extra info received and forwarded to list. Copy sent to aptitude@packages.qa.debian.org. Full text and rfc822 format available.

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

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



Merged 137771 174091. Request was from Matt Zimmerman <mdz@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Merged 137771 161810 174091. Request was from Daniel Burrows <dnb114@psu.edu> to control@bugs.debian.org. Full text and rfc822 format available.

Merged 137771 161810 174091 220794 277719. Request was from Daniel Burrows <dburrows@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Forcibly Merged 137771 161810 174091 220794 277719 453702. Request was from Daniel Burrows <dburrows@debian.org> to control@bugs.debian.org. (Sat, 01 Dec 2007 05:15:10 GMT) Full text and rfc822 format available.

Blocking bugs of 431869 added: 137771, 161810, 174091, 220794, 277719, and 453702 Request was from "Tássia Camões Araújo" <debian@tassia.org> to control@bugs.debian.org. (Wed, 16 Apr 2008 22:03:05 GMT) Full text and rfc822 format available.

Forcibly Merged 137771 146207 161810 174091 220794 277719 453702. Request was from jidanni@jidanni.org to control@bugs.debian.org. (Sat, 30 Aug 2008 03:21:02 GMT) Full text and rfc822 format available.

Forcibly Merged 137771 146207 161810 174091 199887 220794 277719 328616 453702. Request was from jidanni@jidanni.org to control@bugs.debian.org. (Sat, 30 Aug 2008 03:21:04 GMT) Full text and rfc822 format available.

Removed tag(s) sid. Request was from Daniel Hartwig <mandyke@gmail.com> to control@bugs.debian.org. (Tue, 15 May 2012 08:57:10 GMT) Full text and rfc822 format available.

Marked as found in versions aptitude/0.4.11.11-1, aptitude/0.6.4-1.2, and aptitude/0.2.15.8-1; no longer marked as found in versions 0.2.15.8-1. Request was from Daniel Hartwig <mandyke@gmail.com> to control@bugs.debian.org. (Tue, 15 May 2012 09:18:03 GMT) Full text and rfc822 format available.

Added tag(s) confirmed. Request was from Daniel Hartwig <mandyke@gmail.com> to control@bugs.debian.org. (Mon, 02 Jul 2012 05:57:14 GMT) Full text and rfc822 format available.

Added tag(s) help. Request was from Daniel Hartwig <mandyke@gmail.com> to control@bugs.debian.org. (Sat, 15 Sep 2012 15:18:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#137771; Package aptitude. (Thu, 04 Oct 2012 15:06:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Axel Beckert <abe@debian.org>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Thu, 04 Oct 2012 15:06:06 GMT) Full text and rfc822 format available.

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

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



Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#137771; Package aptitude. (Fri, 05 Oct 2012 02:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Hartwig <mandyke@gmail.com>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Fri, 05 Oct 2012 02:48:03 GMT) Full text and rfc822 format available.

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

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



Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#137771; Package aptitude. (Fri, 05 Oct 2012 03:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Hartwig <mandyke@gmail.com>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Fri, 05 Oct 2012 03:00:03 GMT) Full text and rfc822 format available.

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

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



Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#137771; Package aptitude. (Fri, 05 Oct 2012 10:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Axel Beckert <abe@debian.org>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Fri, 05 Oct 2012 10:09:03 GMT) Full text and rfc822 format available.

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

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



Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#137771; Package aptitude. (Fri, 05 Oct 2012 11:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Hartwig <mandyke@gmail.com>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Fri, 05 Oct 2012 11:33:03 GMT) Full text and rfc822 format available.

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

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.



Removed tag(s) confirmed and help. Request was from Daniel Hartwig <mandyke@gmail.com> to control@bugs.debian.org. (Fri, 05 Oct 2012 11:51:05 GMT) Full text and rfc822 format available.

Added indication that 137771 affects release-notes, #, fix, holds, then, update, section, and 4.2.3 Request was from Daniel Hartwig <mandyke@gmail.com> to control@bugs.debian.org. (Fri, 05 Oct 2012 11:51:06 GMT) Full text and rfc822 format available.

Added tag(s) confirmed and help. Request was from Daniel Hartwig <mandyke@gmail.com> to control@bugs.debian.org. (Fri, 05 Oct 2012 12:15:05 GMT) Full text and rfc822 format available.

Removed indication that 137771 affects 4.2.3, holds, fix, then, #, section, and update Added indication that 137771 affects release-notes Request was from Daniel Hartwig <mandyke@gmail.com> to control@bugs.debian.org. (Fri, 05 Oct 2012 12:15:06 GMT) Full text and rfc822 format available.

Removed indication that bug 137771 blocks 431869 Request was from Daniel Hartwig <mandyke@gmail.com> to control@bugs.debian.org. (Fri, 05 Oct 2012 12:15:07 GMT) Full text and rfc822 format available.

Disconnected #328616 from all other report(s). Request was from Daniel Hartwig <mandyke@gmail.com> to control@bugs.debian.org. (Fri, 05 Oct 2012 12:15:08 GMT) Full text and rfc822 format available.

Marked as found in versions aptitude/0.6.8-1. Request was from Daniel Hartwig <mandyke@gmail.com> to control@bugs.debian.org. (Fri, 05 Oct 2012 12:21:10 GMT) Full text and rfc822 format available.

Merged 137771 146207 161810 174091 199887 220794 277719 453702 532189 683099 Request was from Daniel Hartwig <mandyke@gmail.com> to control@bugs.debian.org. (Fri, 05 Oct 2012 12:21:11 GMT) Full text and rfc822 format available.

Marked as found in versions aptitude/0.6.8.1-2. Request was from Axel Beckert <abe@debian.org> to 692017-submit@bugs.debian.org. (Thu, 01 Nov 2012 11:03:03 GMT) Full text and rfc822 format available.

Merged 137771 146207 161810 174091 199887 220794 277719 453702 532189 683099 692017 Request was from Axel Beckert <abe@debian.org> to 692017-submit@bugs.debian.org. (Thu, 01 Nov 2012 11:03:07 GMT) Full text and rfc822 format available.

Severity set to 'important' from 'normal' Request was from Daniel Hartwig <mandyke@gmail.com> to control@bugs.debian.org. (Sat, 08 Dec 2012 06:00:04 GMT) Full text and rfc822 format available.

Added indication that bug 137771 blocks 706770 Request was from Daniel Hartwig <mandyke@gmail.com> to 706770-submit@bugs.debian.org. (Sat, 04 May 2013 23:51:10 GMT) Full text and rfc822 format available.

Merged 137771 146207 161810 174091 199887 220794 277719 453702 532189 683099 692017 729761 Request was from Matthias Klumpp <mak@debian.org> to control@bugs.debian.org. (Thu, 21 Nov 2013 00:06:27 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 02:02:23 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.