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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to