Your message dated Fri, 2 Oct 2015 23:39:52 +0100
with message-id <[email protected]>
and subject line Re: Bug#299009: aptitude: Different package status results 
from command line vs. interactive use
has caused the Debian Bug report #299009,
regarding aptitude: Different package status results from command line vs. 
interactive use
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
299009: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=299009
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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


--- End Message ---
--- Begin Message ---
2015-09-05 21:54 To [email protected]:
Control: severity -1 normal
Control: tags -1 + moreinfo


Hello,

I do not use the command line to make big installations, so I never
observed this discrepancy.  If the problem is still there, it doesn't
seem to happen very often, or in annoying cases that make people
complain about it, because I have seen no complaints lately.

I am not sure why this bug report survived open for so long, but I don't
think that there is much that one can do about it, as the original
developer and maintainer said.  Passing extra packages marked
specifically for "install" is similar to choosing another solution in
the interactive resolver.  Bad decisions of the resolver aside, it is
within the limits of the resolver to offer solutions that remove some
packages.  Also, the internal implementation of aptitude and its
resolver changed a lot during the years.

I am marking it as "moreinfo" because that's what it would have been
needed, but maybe it could also do with a "wontfix" or the non-existing
"notabug".  Probably it should be closed, unless somebody seconds this
or a link is made to bad behaviour of other still-open bug reports.

(The other issues mentioned in the bug report are not well developed and
are present in many other bug reports).

I am closing this now, since as it was noted, the report doesn't contain
information enough that could be used to debug a concrete problem, and
it's not very clear if it's a problem at all or more a result of the way
in which aptitude worked at the time, and possibly choosing alternate
solutions would have worked in the curses interface as well.  As Daniel
Burrows said, the indication of "install these packages" in the command
line and the curses interface are quite different, since the curses
interface is more interactive and open ended.

Some of the problems mentioned about integration with other tools have
been improved, specially in the last few releases (0.7.x); and the
internal implementation of aptitude's resolver changed a lot in the
years after the report.

But basically, the main reason to close it is that it does not provide
clear and enough information to try to investigate.


Cheers.
--
Manuel A. Fernandez Montecelo <[email protected]>

--- End Message ---
_______________________________________________
Aptitude-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel

Reply via email to