Your message dated Mon, 9 Nov 2015 22:41:57 +0000
with message-id <[email protected]>
and subject line Re: Bug#87585: two ways of upgrading (like apt-get)
has caused the Debian Bug report #87585,
regarding two ways of upgrading (like apt-get)
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.)


-- 
87585: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=87585
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: aptitude
Version: 0.0.7.17-1
Severity: wishlist

Currently aptitude with Auto-Upgrade "true" behaves like apt-get dist-upgrade,
it'll sometimes decide to remove a package to be able upgrade some other.

I think that at least for people living on unstable, where things change
constantly it would be sometimes useful if aptitude could behave like apt-get 
upgrade
(ie. better to hold upgrade than remove).

Of course I can always change anything I want on the planned actions screen
or use apt-get upgrade, but I still would like to be able to choose the other
default behavior in aptitude.

Or maybe it's possible with the current set of options, and only I couldn't
make it from the docs?

-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux Amber 2.2.17 #1 Tue Dec 12 23:19:33 CET 2000 i586

Versions of packages aptitude depends on:
pi  apt [libapt-pkg3.1]           0.5.0      Advanced front-end for dpkg       
ii  libc6                         2.2.2-1    GNU C Library: Shared libraries an
ii  libncurses5                   5.0-8      Shared libraries for terminal hand
ii  libstdc++2.10-glibc2.2        1:2.95.3-5 The GNU stdc++ library            

-- 
MichaƂ Politowski
[email protected]


--- End Message ---
--- Begin Message ---
tags 87585 + wontfix
stop


2001-02-25 15:25 Daniel Burrows:
On Sun, Feb 25, 2001 at 03:29:50PM +0100, Michal Politowski 
<[email protected]> was heard to say:
Currently aptitude with Auto-Upgrade "true" behaves like apt-get dist-upgrade,
it'll sometimes decide to remove a package to be able upgrade some other.

I think that at least for people living on unstable, where things change
constantly it would be sometimes useful if aptitude could behave like apt-get 
upgrade
(ie. better to hold upgrade than remove).

Of course I can always change anything I want on the planned actions screen
or use apt-get upgrade, but I still would like to be able to choose the other
default behavior in aptitude.

Or maybe it's possible with the current set of options, and only I couldn't
make it from the docs?

 I'll look into this when I get a chance..right now my major focus is on
improving the UI, but this sort of stuff should matter too :/  Time is the
main factor here (, not enough of to do everything)

 I think I see how to do this, actually.  Unfortunately it's going to be
pretty hard to test..

 -- Daniel "where'd I put my stasis field?" Burrows


2007-12-24 23:37 Daniel Burrows:
On Sun, Dec 23, 2007 at 03:45:33PM -0430, Jose Luis Rivas Contreras 
<[email protected]> was heard to say:
This was implemented already wasn't it? With safe-upgrade and
full-upgrade, so this bug should be closed.

 I believe the request was referring to visual mode, where you currently
can't easily do an upgrade without allowing aptitude fairly free choice
in the decisions it makes.


If this hasn't been implemented in 14 years, and there were no input
since 8 years ago (other than unrelated messages), and no seconds
anyway, it's pretty clear that this is not going to be implemented.

Back in 2001 it could be justified to change the behaviour of such basic
functionality (no need for backward compatibility), but in 2015 this
isn't the case IMO.

Apart from that, the behaviour described and many other details are
obsolate by now.

The resolver response can now be tweaked in other ways since ~2008 /
~2010, and so some or all of the desired effects are achieved in other
ways (but one has to get the hands dirty).

Thus, closing.

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