Debian Bug report logs - #299009
aptitude: Different package status results from command line vs. interactive use

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: "Karsten M. Self" <kmself@ix.netcom.com>

Date: Fri, 11 Mar 2005 03:33:02 UTC

Severity: important

Found in version 0.2.15.8-1

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>:
Bug#299009; Package aptitude. Full text and rfc822 format available.

Acknowledgement sent to "Karsten M. Self" <kmself@ix.netcom.com>:
New Bug report received and forwarded. Copy sent to Daniel Burrows <dburrows@debian.org>. Full text and rfc822 format available.

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

From: "Karsten M. Self" <kmself@ix.netcom.com>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: aptitude: Different package status results from command line vs. interactive use
Date: Thu, 10 Mar 2005 19:30:32 -0800
Package: aptitude
Version: 0.2.15.8-1
Severity: important


Note:  the problem in question was noted on a different system, though
IRC discussion in #debian and #debian-devel indicates others are seeing
this issue with various versions of aptitude.  Version numbers will
differ slightly, should be whatever's current in Sarge as of two days
ago.


In a recent (3 day old) netinst of Sarge, a number of packages were
installed via an interactive (full-screen) aptitude session.

After completion of this install and exiting the session, several
additional packages were specified for install in command-line mode:

   aptitude install <package list>

Aptitude proceeded to list approximately 100 packages for removal.  The
action was canceled, the removed packages listed to a file, and a
revised install command issued including the file contents:

   aptitude install <package list> $( cat file )

...which proceeded successfully.

There wasn't time to investigate _why_ the packages were marked for
removal, however _none_ of these packages generated any conflicts when
requested in conjunction with the packages initially requested in the
command-line install.



Problem:  aptitude should produce consistent results when used from
command-line and interactively.

There are several existing issues with aptitude not respecting
packagelists supplied via dpkg and dselect as well.

I have grave concerns that aptitude itself being sufficiently usable for
inclusion in a stable Debian release.  I say this as a fan of aptitude.


Workarounds:  It's relatively easy to resolve the problem as I did, by
passing the list of removed packages on the "install" command.  However
this requires the user be aware of the problem up front.  Recovery from
large-scale package removal may be difficult or time-consuming,
particularly on dialup or standalone systems in which package cache has
expired.

The aptitude manpage should have a BUGS section listing this
discrepency between interactive and commandline usage, and suggested
workarounds (as above).


Ideally, the problem should be fixed by having aptitude use consistent
package-registration and dependency resolution routines in all modes.
aptitude should also play nice with other packaging tools, including
apt-get, dpkg, and dselect.


-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (950, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.7-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages aptitude depends on:
ii  apt [libapt-pkg-libc6.3-5-3 0.5.28.1     Advanced front-end for dpkg
ii  libc6                       2.3.2.ds1-20 GNU C Library: Shared libraries an
ii  libgcc1                     1:3.4.3-6    GCC support library
ii  libncurses5                 5.4-4        Shared libraries for terminal hand
ii  libsigc++-1.2-5c102         1.2.5-1      Type-safe Signal Framework for C++
ii  libstdc++5                  1:3.3.5-8    The GNU Standard C++ Library v3

-- no debconf information



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

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

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

From: Daniel Burrows <dburrows@debian.org>
To: "Karsten M. Self" <kmself@ix.netcom.com>, 299009@bugs.debian.org
Subject: Re: Bug#299009: aptitude: Different package status results from command line vs. interactive use
Date: Sat, 23 Apr 2005 13:23:01 -0400
[Message part 1 (text/plain, inline)]
On Thursday 10 March 2005 10:30 pm, Karsten M. Self wrote:
> Note:  the problem in question was noted on a different system, though
> IRC discussion in #debian and #debian-devel indicates others are seeing
> this issue with various versions of aptitude.  Version numbers will
> differ slightly, should be whatever's current in Sarge as of two days
> ago.
>
>
> In a recent (3 day old) netinst of Sarge, a number of packages were
> installed via an interactive (full-screen) aptitude session.
>
> After completion of this install and exiting the session, several
> additional packages were specified for install in command-line mode:
>
>    aptitude install <package list>
>
> Aptitude proceeded to list approximately 100 packages for removal.  The
> action was canceled, the removed packages listed to a file, and a
> revised install command issued including the file contents:
>
>    aptitude install <package list> $( cat file )
>
> ...which proceeded successfully.
>
> There wasn't time to investigate _why_ the packages were marked for
> removal, however _none_ of these packages generated any conflicts when
> requested in conjunction with the packages initially requested in the
> command-line install.

  I have no way of figuring out what happened here without more information.

> Problem:  aptitude should produce consistent results when used from
> command-line and interactively.

  Well, the reason you see this is that the command-line interaction is 
different than visual mode.  At the command-line, aptitude knows that its job 
is to perform a certain set of actions and preferably as few others as 
possible (for instance, "aptitude install X Y Z" should install packages X, 
Y, and Z).  aptitude is able to give corresponding hints to the problem 
resolver, basically saying "come hell or high water, make sure you preserve 
the states of these packages" (in the previous example, "don't cancel the 
installations of X, Y, and Z").

  In visual mode, in contrast, the interaction between the user and the 
program is a lot more open-ended, and it's a lot trickier to figure out 
exactly what the user wants (in fact, I'm not sure it's even possible in 
principle).  So aptitude gives the problem resolver a vaguer set of 
instructions, basically "try and find a reasonable solution if you can".

> There are several existing issues with aptitude not respecting
> packagelists supplied via dpkg and dselect as well.

  Yes, I believe there are other bugs filed about that (aptitude wanting to 
remove stuff installed with dpkg).  Some of this has been fixed in the 
experimental branch, but there may be problems remaining.

> Workarounds:  It's relatively easy to resolve the problem as I did, by
> passing the list of removed packages on the "install" command.  However
> this requires the user be aware of the problem up front.  Recovery from
> large-scale package removal may be difficult or time-consuming,
> particularly on dialup or standalone systems in which package cache has
> expired.

  Yes, never ever ever install packages without first checking that the 
program is doing something sensible.  Even the most perfect problem 
resolution algorithm is guaranteed to do things you don't want sometimes. [0] 
I have been looking into ways of preventing the resolver from going nuts and 
removing half the system, but it can be bad enough if just one package that's 
important to you is removed...

  Daniel

  [0] The reason for this is that the ideal solution is not just a function of 
the sets of available packages/version and their dependency relationship; 
some of the information needed to compute it is in the user's head, in a 
manner of speaking.

-- 
/------------------- Daniel Burrows <dburrows@debian.org> ------------------\
|   "That we should wish to cast him down and have no one in his place      |
|    is not a thought that occurs to his mind. That we should wish to       |
|    destroy the Ring itself has not yet entered into his darkest dream."   |
|     -- Gandalf Grayhame                                                   |
\--------------------- A duck! -- http://www.python.org --------------------/
[Message part 2 (application/pgp-signature, inline)]

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 24 04:54:48 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.