aptitude has private package holds, should use dpkg

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

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

  Daniel

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

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

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

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

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

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

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

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

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

  That might be nice.

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

  That might also be nice.

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

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

  Daniel

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

On Sat, 4 May 2002, Daniel Burrows wrote:

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

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

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

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

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

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

                                 Best regards, Faheem Mitha.

(.aptitude/config)

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

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

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

  Daniel

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

On Tue, 7 May 2002, Daniel Burrows wrote:

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

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

                                                         Faheem.

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

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

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

  Daniel

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

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

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

thanks

--
 - mdz

severity 161810 normal
merge 161810 137771
thanks

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

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

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

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

package apticron
block 431869 by 137771
thanks

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

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

Regards,

--
Tássia Camões Araújo

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