[Aptitude-devel] Bug#428825: aptitude: Seems to install *only* new packages upon dist-upgrade

[Manuel A. Fernandez Montecelo]

Control: severity -1 wishlist
Control: tags -1 + wontfix


Hi Frank,

2007-06-19 01:03 Daniel Burrows:
>On Mon, Jun 18, 2007 at 11:24:57AM +0200, Frank Küster <frank at kuesterei.ch> was heard to say:
>> Daniel Burrows <dburrows at debian.org> wrote:
>> >   It sounds like you're saying I shouldn't display the state of the
>> > program before resolving dependencies?  Wouldn't that be horribly
>> > confusing if some of the automatically installed packages had dependency
>> > errors?  "huh?  Why do I care that libherring43 had dependency problems?
>> > I didn't ask you to install that!"
>>
>> Yes, that would be confusing, too.  The "standard resolver" output you
>> posted in an other mail would be clearer.
>>
>> And in my case, it would have been good to indicate that, as a side
>> effect of holding back A, B and C, also the 70 other packages which were
>> displayed as "NEW packages are going to be installed" will be "kept at
>> their current version: (none)".
>
>  OK, I'm completely lost in this discussion.  I need to get my bearings
>again.  :-)

Me too!


>  I believe that we agree that the autoinstalls which aptitude does
>before displaying a prompt should be explicitly output in dependency
>order, or at least you should be able to get that information from
>the prompt.  So you get something like:
>
>
>Automatically resolving dependencies...
>  wesnoth Depends wesnoth-data
>  ...
>
>Continue? [Y/n]
>
>
>I like this idea, although for very large installs, like the one that
>started this bug, I wonder if this would be counterproductive.  The
>information that I really need to produce this output is tied up in apt
>right now, unfortunately.

I think that this would be very counterproductive, because there are
lots of packages that depend on a large amount of packages, and in cases
like the recent gcc-5/c++11 transition in which hundreds of libraries
were renamed to have 'v5' in their name, several screenfuls of lines
would not help to make the situation more clear at all.  And these
situations are not so atypical when it involves popular codecs or basic
libraries.

On the other hand, using the curses mode of aptitude or the "why"
command, can help to explain the situation when one is really interested
in digging.


Independently of this, I am quite sure that nobody from the APT team
wants to implement this functionality, and both apt and aptitude's
maintainers are quite busy with many other more important problems
popping up.  So at the moment, I am marking it as +wontfix, because in
reality I cannot see that this is going to be implemented anytime soon
-- as it was not implemented in the 8 years in between.


>> Something like
>>
>>   Resolving dependencies...
>>   The following actions will resolve these dependencies:
>>
>>   Keep the following packages at their current version:
>>   apt [0.6.46.4-0.1 (now)]
>>   apt-utils [0.6.46.4-0.1 (now)]
>>   libsasl2-2 [2.1.22.dfsg1-10 (now)]
>>   python-apt [0.6.21 (now)]
>> +
>> + Do not install NEW depended-on or recommended packages:
>> + libbla, libfasel, libblubber, pciutils, pci-inutils, ...
>>
>>   Score is -30
>
>  Here, are you referring to the fact that aptitude cancels
>installations that are no longer necessary after dependencies are
>resolved?  I think that's what you're saying, and yeah, I think it would
>be good if aptitude could detect which packages would be kicked out by
>the autoremoval after applying a solution.  This will be somewhat
>difficult to do with the new apt logic, though.  If I had the option of
>refactoring it a little, I could add appropriate hooks, though...

Again, I am quite lost here, but I think that this is printed now with
"recommended but not installed packages".


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>