Bug#428825: aptitude: Seems to install *only* new packages upon dist-upgrade
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 was heard to say: Daniel Burrows 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
Bug#428825: aptitude: Seems to install *only* new packages upon dist-upgrade
Daniel Burrows <[EMAIL PROTECTED]> wrote:
> 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.
Agreed.
> 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.
AFAICS it was one binary package ("foo") which had a new dependency
("bar"), which in turn pulled in all the rest. In this case it would be
sufficiently clear, and easier to read in large installs, if we only had
foo Depends bar
bar Pulls in baz, fee, faa, fuu, rubber, dubber, doo.
without specifying in detail how the dependency/recommendency chain
leads from bar to doo.
>> +
>> + 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,
Yes, that's what I meant.
> I'm sorry if I'm really out in left field here or not following
> your messages. I feel like I'm missing out on an important point -- could
> you maybe try pounding it into my head again? :)
No, I think these are the main points that are left after I understand
what was going on.
Thanks, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Bug#428825: aptitude: Seems to install *only* new packages upon dist-upgrade
On Mon, Jun 18, 2007 at 11:24:57AM +0200, Frank Küster <[EMAIL PROTECTED]> was heard to say: > Daniel Burrows <[EMAIL PROTECTED]> 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. :-) 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. > 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... I'm sorry if I'm really out in left field here or not following your messages. I feel like I'm missing out on an important point -- could you maybe try pounding it into my head again? :) Daniel
Bug#428825: aptitude: Seems to install *only* new packages upon dist-upgrade
Daniel Burrows <[EMAIL PROTECTED]> wrote: >> Or by not displaying anything as "will be installed/upgraded" before >> aptitude is sure that it will do that, or would if the user hits >> [enter]. Of course if a proposed solution to a dependency problem >> involves upgrading and installing new packages, that should both be >> indicated as part of the solution. But just displaying the result of >> "upgrade and install as much as possible" first, and later telling the >> user that this doesn't work, this is a suboptimal way to interact with >> the poor user... > > 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)". 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 Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#428825: aptitude: Seems to install *only* new packages upon dist-upgrade
Daniel Burrows <[EMAIL PROTECTED]> wrote: >> Why does it not install the recommended package? In the UI, I have >> selected to install Recommends. > > ... and also it's the default. > >> # cat $HOME/.aptitude/config >> aptitude ""; >> aptitude::Keep-Unused-Pattern ""; >> aptitude::Delete-Unused-Pattern ""; > > That's root's $HOME, right? Just to check, what's in your own > home directory's .aptitude/config (if it exists)? [EMAIL PROTECTED]:~$ cat $HOME/.aptitude cat: /home/frank/.aptitude: No such file or directory [EMAIL PROTECTED]:~$ Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#428825: aptitude: Seems to install *only* new packages upon dist-upgrade
On Fri, Jun 15, 2007 at 04:50:35PM +0200, Frank Küster <[EMAIL PROTECTED]> was heard to say: > Daniel Burrows <[EMAIL PROTECTED]> wrote: > > So the only bug I see here is that it's too hard to get a sensible > > explanation of where autoinstalls (the ones done internally by libapt) > > come from. > > One thing that would have helped me was if aptitude would make it > clearer that it displays actually two separate screens: > > - one in which apt, libapt and python-apt are upgraded, and "a couple > of" new packages are installed > > - and a second one in which apt, libapt and python-apt are held back, > and *no* new packages are installed. I'm not sure what you mean? > Or by not displaying anything as "will be installed/upgraded" before > aptitude is sure that it will do that, or would if the user hits > [enter]. Of course if a proposed solution to a dependency problem > involves upgrading and installing new packages, that should both be > indicated as part of the solution. But just displaying the result of > "upgrade and install as much as possible" first, and later telling the > user that this doesn't work, this is a suboptimal way to interact with > the poor user... 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!" Daniel
Bug#428825: aptitude: Seems to install *only* new packages upon dist-upgrade
On Fri, Jun 15, 2007 at 04:58:14PM +0200, Frank Küster <[EMAIL PROTECTED]> was heard to say: > Daniel Burrows <[EMAIL PROTECTED]> wrote: > > Aha. If you look at the aptitude output earlier in your mail, it looks > > like lsb-core is required by lsb. lsb is recommended by lsb-release, and > > lsb-release is required by python-apt. > > > > So the only bug I see here is that it's too hard to get a sensible > > explanation of where autoinstalls (the ones done internally by libapt) > > come from. > > Yes, that seems to be the point. I'm not sure how to make that clearer, > though. This upgrade scenario seems to be a very special case. If aptitude jumps into its regular resolver, you can get output like python-apt Depends lsb-release --> installing lsb-release lsb-release Recommends lsb --> installing lsb lsb Depends lsb-core --> installing lsb-core ... I think that might help a little. Now that Michael has merged the automarking patch, maybe I should see if I can hack apt so that it instruments its autoinstalls with the information I'd need to do a topological sort like this. It's been a persistent problem for ages; "-D" tries to reverse-engineer apt to figure out what just happened, but it can't provide this level of detail. > Here's one more strange thing. In order to investigate what happens, I > did this: > > # aptitude install lsb-release > Reading package lists... Done > Building dependency tree... Done > Reading extended state information > Initializing package states... Done > Building tag database... Done > The following packages have been kept back: > apt apt-utils libsasl2-2 python-apt > The following NEW packages will be installed: > lsb-release > The following packages are RECOMMENDED but will NOT be installed: > lsb > 0 packages upgraded, 1 newly installed, 0 to remove and 4 not upgraded. > Need to get 16,2kB of archives. After unpacking 45,1kB will be used. > Writing extended state information... Done > Get:1 http://localhost sid/main lsb-release 3.1-23.1 [16,2kB] > Fetched 16,2kB in 0s (88,4kB/s) > Selecting previously deselected package lsb-release. > (Reading database ... 73681 files and directories currently installed.) > Unpacking lsb-release (from .../lsb-release_3.1-23.1_all.deb) ... > Setting up lsb-release (3.1-23.1) ... > > Why does it not install the recommended package? In the UI, I have > selected to install Recommends. ... and also it's the default. > # cat $HOME/.aptitude/config > aptitude ""; > aptitude::Keep-Unused-Pattern ""; > aptitude::Delete-Unused-Pattern ""; That's root's $HOME, right? Just to check, what's in your own home directory's .aptitude/config (if it exists)? Daniel
Bug#428825: aptitude: Seems to install *only* new packages upon dist-upgrade
Daniel Burrows <[EMAIL PROTECTED]> wrote: >> > If you jump into >> > the visual UI (run without any argument) or run "aptitude install", do you >> > still see all that stuff being installed? >> >> Running the TUI and pressing "g" gives nothing except the remark about >> the held-back apt stuff, "aptitude install" is silent. Even more >> strange, with all those supposedly unmet dependencies? Let's have a >> look what dpkg thinks: > > Hm, so those two commands *DON'T* install all that extra stuff? No, the don't install it. There doesn't seem to be a reason for that... >> I don't get it. As a test, I have now installed one of the libs which >> aptitude wanted (libpci2, one which doesn't pull in anything) and tried again >> dist-upgrade - no change. In the TUI, no information is shown for a >> view of the packages I tried which would discriminate them from all s/view/few/... > Aha. If you look at the aptitude output earlier in your mail, it looks > like lsb-core is required by lsb. lsb is recommended by lsb-release, and > lsb-release is required by python-apt. > > So the only bug I see here is that it's too hard to get a sensible > explanation of where autoinstalls (the ones done internally by libapt) > come from. Yes, that seems to be the point. I'm not sure how to make that clearer, though. This upgrade scenario seems to be a very special case. Here's one more strange thing. In order to investigate what happens, I did this: # aptitude install lsb-release Reading package lists... Done Building dependency tree... Done Reading extended state information Initializing package states... Done Building tag database... Done The following packages have been kept back: apt apt-utils libsasl2-2 python-apt The following NEW packages will be installed: lsb-release The following packages are RECOMMENDED but will NOT be installed: lsb 0 packages upgraded, 1 newly installed, 0 to remove and 4 not upgraded. Need to get 16,2kB of archives. After unpacking 45,1kB will be used. Writing extended state information... Done Get:1 http://localhost sid/main lsb-release 3.1-23.1 [16,2kB] Fetched 16,2kB in 0s (88,4kB/s) Selecting previously deselected package lsb-release. (Reading database ... 73681 files and directories currently installed.) Unpacking lsb-release (from .../lsb-release_3.1-23.1_all.deb) ... Setting up lsb-release (3.1-23.1) ... Why does it not install the recommended package? In the UI, I have selected to install Recommends. # cat $HOME/.aptitude/config aptitude ""; aptitude::Keep-Unused-Pattern ""; aptitude::Delete-Unused-Pattern ""; Anyway, after installing lsb-release "aptitude dist-upgrade" behaves more understandable, it says The following packages will be upgraded: apt apt-utils libsasl2-2 python-apt and later it reports the problem about aptitude and the suggestion of holding back those packages. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#428825: aptitude: Seems to install *only* new packages upon dist-upgrade
Daniel Burrows <[EMAIL PROTECTED]> wrote: > So the only bug I see here is that it's too hard to get a sensible > explanation of where autoinstalls (the ones done internally by libapt) > come from. One thing that would have helped me was if aptitude would make it clearer that it displays actually two separate screens: - one in which apt, libapt and python-apt are upgraded, and "a couple of" new packages are installed - and a second one in which apt, libapt and python-apt are held back, and *no* new packages are installed. This could be achieved either by indicating that not installing the new packages is part of the suggested solution. Or by not displaying anything as "will be installed/upgraded" before aptitude is sure that it will do that, or would if the user hits [enter]. Of course if a proposed solution to a dependency problem involves upgrading and installing new packages, that should both be indicated as part of the solution. But just displaying the result of "upgrade and install as much as possible" first, and later telling the user that this doesn't work, this is a suboptimal way to interact with the poor user... Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#428825: aptitude: Seems to install *only* new packages upon dist-upgrade
On Thu, Jun 14, 2007 at 05:25:10PM +0200, Frank Küster <[EMAIL PROTECTED]> was heard to say: > Daniel Burrows <[EMAIL PROTECTED]> wrote: > > > What do you get here if you pass -D at the command line? I bet you > > get just the same thing back... > > Yes, with lots of Ds and Ss and Rs: [snip] > > If you look at your aptitude log, does aptitude say it wanted to install > > all this stuff on a previous run? > > No, it doesn't seem so, neither looking manually at the last couple of > runs, nor > > egrep '(rsync|rpm|pcituils)' /var/log/aptitude > > Also, are there any currently broken > > packages? (e.g., run "apt-cache unmet | grep Depends") > > Oh, apt-cache reports lots of. I'm really surprised that this hasn't > shown up earlier. I have dist-upgraded this chroot once or twice a week > usually, sometimes not for two weeks, but I don't remember any errors. Interesting. > I also cannot understand why aptitude wants to install the packages it > told me, while the packages it needs seem to be quite unrelated. Three > packages around with the output of apt-cache unmet clusters seem to be > apache-common, icedove and enigmail, but these packages were not > selected by aptitude: That's more surprising. When aptitude breaks into the resolver, it tries to fix *all* the broken packages it can see. > Package icedove-locale-sk version 1:1.5.0.8-1 has an unmet dep: > Depends: icedove (<= 1.5.0.99) I recommended "apt-cache unmet" without taking a good look at it :-/. [EMAIL PROTECTED]:~$ apt-cache unmet | grep -B 1 Depends | head --lines 5 Package dia-libs version 0.94.0-17.1etch1 has an unmet dep: Depends: python2.3 (>= 2.3) -- Package libestraier7 version 1.0.6-1.1etch1 has an unmet dep: Depends: libqdbm11 Neither dia-libs nor libestraier is installed on my computer. So that output is not useful: it just displays unmet dependencies without checking if the depender is installed. > > If you jump into > > the visual UI (run without any argument) or run "aptitude install", do you > > still see all that stuff being installed? > > Running the TUI and pressing "g" gives nothing except the remark about > the held-back apt stuff, "aptitude install" is silent. Even more > strange, with all those supposedly unmet dependencies? Let's have a > look what dpkg thinks: Hm, so those two commands *DON'T* install all that extra stuff? > > Usually output like this means that a previous install aborted (e.g., > > because of package installation errors) and aptitude is trying to complete > > it. Certainly there's something installed on your system that requires > > those packages, or aptitude would have dropped them as being unused > > I don't get it. As a test, I have now installed one of the libs which > aptitude wanted (libpci2, one which doesn't pull in anything) and tried again > dist-upgrade - no change. In the TUI, no information is shown for a > view of the packages I tried which would discriminate them from all > those thousands which aptitude does not want to touch. In particular, > no package is shown to depend on pciutils, ... > > Ah, here is something. lsb-core is among those which aptitude wanted to > install. > > p--\ lsb-core 3.1-23.1 > [...] > --\ Depends > --- alien (>= 8.36) (UNSATISFIED) > --- at (UNSATISFIED) > --- bc (UNSATISFIED) > [...] > > But no package is shown to Depend on it. How can I find out whether any > installed package Recommends it? And why are alien, at, bc and more > marked as unsatisfied? They are not installed, but they easily could: Aha. If you look at the aptitude output earlier in your mail, it looks like lsb-core is required by lsb. lsb is recommended by lsb-release, and lsb-release is required by python-apt. So the only bug I see here is that it's too hard to get a sensible explanation of where autoinstalls (the ones done internally by libapt) come from. Daniel
Bug#428825: aptitude: Seems to install *only* new packages upon dist-upgrade
Daniel Burrows <[EMAIL PROTECTED]> wrote: > What do you get here if you pass -D at the command line? I bet you > get just the same thing back... Yes, with lots of Ds and Ss and Rs: The following packages are BROKEN: aptitude (D: libapt-pkg-libc6.3-6-3.11) The following NEW packages will be automatically installed: alien (D: lsb-core, S: rpm) at (D: lsb-core) bc (D: lsb-core) dbus (D: dbus-x11, R: libdbus-1-3) dbus-x11 (D: dbus) fontconfig (D: libpango1.0-common, D: libqt3-mt, D: libqt4-gui, D: lsb-desktop) groff-base (D: man-db) hicolor-icon-theme (R: libgtk2.0-0) libatk1.0-0 (D: libatk1.0-data, D: libgtk2.0-0, D: lsb-desktop) libatk1.0-data (R: libatk1.0-0) libaudio2 (D: libqt3-mt, D: libqt4-gui, D: libqt4-qt3support, D: qt4-qtconfig, R: libaudio2) libbeecrypt6 (D: librpm4, D: rpm) libcupsys2 (D: libgtk2.0-0) libdatrie0 (D: libpango1.0-0, D: libthai0) libdbus-1-3 (D: dbus, D: libqt4-core) libgl1-mesa-glide3 (D: libglu1-mesa, D: libqt4-gui, D: lsb-graphics, R: libqt3-mt, R: libgl1-mesa-glide3) libglib2.0-0 (D: libatk1.0-0, D: libglib2.0-data, D: libgtk2.0-0, D: libpango1.0-0, D: libqt4-core, D: libqt4-gui, D: libqt4-qt3support, D: libqt4-sql, D: lsb-desktop, D: qt4-qtconfig) libglib2.0-data (R: libglib2.0-0) libglide3 (D: libgl1-mesa-glide3, R: libglide3) libglu1-mesa (D: libgl1-mesa-glide3, D: libqt4-gui, R: libqt3-mt, R: libglu1-mesa) libgtk2.0-0 (D: libgtk2.0-bin, D: lsb-desktop, R: libgtk2.0-common) libgtk2.0-bin (R: libgtk2.0-0) libgtk2.0-common (D: libgtk2.0-0) liblcms1 (D: libmng1, R: liblcms1) liblockfile1 (D: mailx) libmng1 (D: libqt3-mt, D: libqt4-gui) libmysqlclient15off (D: libqt4-qt3support, D: libqt4-sql, D: qt4-qtconfig) libneon25 (D: librpm4) libpango1.0-0 (D: libgtk2.0-0, D: lsb-desktop, R: libpango1.0-common) libpango1.0-common (D: libpango1.0-0) libpci2 (D: pciutils) libpq5 (D: libqt4-qt3support, D: libqt4-sql, D: qt4-qtconfig) libqt3-mt (D: lsb-desktop) libqt4-core (D: libqt4-gui, D: libqt4-qt3support, D: libqt4-sql, D: qt4-qtconfig) libqt4-gui (D: libqt4-qt3support, D: lsb-qt4, D: qt4-qtconfig) libqt4-qt3support (D: qt4-qtconfig) libqt4-sql (D: libqt4-qt3support, D: qt4-qtconfig) librpm4 (D: rpm) libsqlite0 (D: libqt4-qt3support, D: libqt4-sql, D: qt4-qtconfig) libsqlite3-0 (D: librpm4) libthai-data (D: libthai0) libthai0 (D: libpango1.0-0) libtiff4 (D: libgtk2.0-0) libxcursor1 (D: libgtk2.0-0, D: libqt3-mt, D: libqt4-gui, D: libqt4-qt3support, D: qt4-qtconfig) libxfixes3 (D: libgtk2.0-0, D: libqt4-gui, D: libqt4-qt3support, D: libxcursor1, D: qt4-qtconfig) libxft2 (D: libpango1.0-0, D: libqt3-mt) libxi6 (D: libgtk2.0-0, D: libqt3-mt) libxinerama1 (D: libgtk2.0-0, D: libqt3-mt, D: libqt4-gui, D: libqt4-qt3support, D: qt4-qtconfig) libxml2 (D: libneon25, D: lsb-desktop) libxrandr2 (D: libgtk2.0-0, D: libqt3-mt, D: libqt4-gui, D: libqt4-qt3support, D: qt4-qtconfig) libxxf86dga1 (D: libglide3) libxxf86vm1 (D: libglide3) lprng (D: lsb-core, R: lprng) lsb (R: lsb-release) lsb-core (D: lsb, D: lsb-cxx, D: lsb-graphics) lsb-cxx (D: lsb) lsb-desktop (D: lsb, D: lsb-qt4) lsb-graphics (D: lsb, D: lsb-desktop) lsb-qt4 (D: lsb) lsb-release (D: lsb-core, D: python-apt) mailx (D: lsb-core, S: exim4-base, S: sharutils) man-db (D: lsb-core, R: man-db) mysql-common (D: libmysqlclient15off) ncurses-term (D: lsb-core, R: ncurses-base) pax (D: lsb-core) pciutils (D: libglide3) procps (D: lsb-core, R: procps) qt4-qtconfig (R: libqt4-gui) rpm (D: alien) rsync (D: lsb-core) x-ttcidfont-conf (R: libpango1.0-common, S: defoma) The following NEW packages will be installed: [...] > If you look at your aptitude log, does aptitude say it wanted to install > all this stuff on a previous run? No, it doesn't seem so, neither looking manually at the last couple of runs, nor egrep '(rsync|rpm|pcituils)' /var/log/aptitude > Also, are there any currently broken > packages? (e.g., run "apt-cache unmet | grep Depends") Oh, apt-cache reports lots of. I'm really surprised that this hasn't shown up earlier. I have dist-upgraded this chroot once or twice a week usually, sometimes not for two weeks, but I don't remember any errors. I also cannot understand why aptitude wants to install the packages it told me, while the packages it needs seem to be quite unrelated. Three packages around with the output of apt-cache unmet clusters seem to be apache-common, icedove and enigmail, but these packages were not selected by aptitude: >From apt-cache unmet | egrep -v '(Suggests|Recommends)', only a small selection: Package icedove-locale-sk version 1:1.5.0.8-1 has an unmet dep: Depends: icedove (<= 1.5.0.99) Package python-tagpy version 0.91-1 has an unmet dep: Depends: libboost-python1.33.1 Package icedove-locale-sl version 1:1.5.0.8-1 has an unmet dep: Depends: icedove (<= 1.5.0.99) Package libapache-mod-ruby version 1.2.6-1.1 has an unmet dep: Depends: apache-common Pac
Bug#428825: aptitude: Seems to install *only* new packages upon dist-upgrade
On Thu, Jun 14, 2007 at 03:25:34PM +0200, Frank Küster <[EMAIL PROTECTED]> was heard to say: > Hi, now that I've closed an aptitude non-bug today, may I submit a new > one? Sure, but only if it's a non-bug. :-) > Today, when I call aptitude dist-upgrade on sid, aptitude seems to > install new packages because some upgraded package depends on them: > > *** > Reading package lists... Done > Building dependency tree... Done > Reading extended state information > Initializing package states... Done > Building tag database... Done > The following packages are BROKEN: > aptitude > The following NEW packages will be automatically installed: > alien at bc dbus dbus-x11 fontconfig groff-base hicolor-icon-theme > libatk1.0-0 libatk1.0-data libaudio2 > libbeecrypt6 libcupsys2 libdatrie0 libdbus-1-3 libgl1-mesa-glide3 > libglib2.0-0 libglib2.0-data libglide3 > libglu1-mesa libgtk2.0-0 libgtk2.0-bin libgtk2.0-common liblcms1 > liblockfile1 libmng1 libmysqlclient15off > libneon25 libpango1.0-0 libpango1.0-common libpci2 libpq5 libqt3-mt > libqt4-core libqt4-gui libqt4-qt3support > libqt4-sql librpm4 libsqlite0 libsqlite3-0 libthai-data libthai0 libtiff4 > libxcursor1 libxfixes3 libxft2 libxi6 > libxinerama1 libxml2 libxrandr2 libxxf86dga1 libxxf86vm1 lprng lsb lsb-core > lsb-cxx lsb-desktop lsb-graphics > lsb-qt4 lsb-release mailx man-db mysql-common ncurses-term pax pciutils > procps qt4-qtconfig rpm rsync > x-ttcidfont-conf What do you get here if you pass -D at the command line? I bet you get just the same thing back... If you look at your aptitude log, does aptitude say it wanted to install all this stuff on a previous run? Also, are there any currently broken packages? (e.g., run "apt-cache unmet | grep Depends") If you jump into the visual UI (run without any argument) or run "aptitude install", do you still see all that stuff being installed? Usually output like this means that a previous install aborted (e.g., because of package installation errors) and aptitude is trying to complete it. Certainly there's something installed on your system that requires those packages, or aptitude would have dropped them as being unused. Although that's a whole lot of packages to have in the queue. Daniel
Bug#428825: aptitude: Seems to install *only* new packages upon dist-upgrade
Package: aptitude Version: 0.4.4-4 Severity: normal Hi, now that I've closed an aptitude non-bug today, may I submit a new one? Today, when I call aptitude dist-upgrade on sid, aptitude seems to install new packages because some upgraded package depends on them: *** Reading package lists... Done Building dependency tree... Done Reading extended state information Initializing package states... Done Building tag database... Done The following packages are BROKEN: aptitude The following NEW packages will be automatically installed: alien at bc dbus dbus-x11 fontconfig groff-base hicolor-icon-theme libatk1.0-0 libatk1.0-data libaudio2 libbeecrypt6 libcupsys2 libdatrie0 libdbus-1-3 libgl1-mesa-glide3 libglib2.0-0 libglib2.0-data libglide3 libglu1-mesa libgtk2.0-0 libgtk2.0-bin libgtk2.0-common liblcms1 liblockfile1 libmng1 libmysqlclient15off libneon25 libpango1.0-0 libpango1.0-common libpci2 libpq5 libqt3-mt libqt4-core libqt4-gui libqt4-qt3support libqt4-sql librpm4 libsqlite0 libsqlite3-0 libthai-data libthai0 libtiff4 libxcursor1 libxfixes3 libxft2 libxi6 libxinerama1 libxml2 libxrandr2 libxxf86dga1 libxxf86vm1 lprng lsb lsb-core lsb-cxx lsb-desktop lsb-graphics lsb-qt4 lsb-release mailx man-db mysql-common ncurses-term pax pciutils procps qt4-qtconfig rpm rsync x-ttcidfont-conf The following NEW packages will be installed: alien at bc dbus dbus-x11 fontconfig groff-base hicolor-icon-theme libatk1.0-0 libatk1.0-data libaudio2 libbeecrypt6 libcupsys2 libdatrie0 libdbus-1-3 libgl1-mesa-glide3 libglib2.0-0 libglib2.0-data libglide3 libglu1-mesa libgtk2.0-0 libgtk2.0-bin libgtk2.0-common liblcms1 liblockfile1 libmng1 libmysqlclient15off libneon25 libpango1.0-0 libpango1.0-common libpci2 libpq5 libqt3-mt libqt4-core libqt4-gui libqt4-qt3support libqt4-sql librpm4 libsqlite0 libsqlite3-0 libthai-data libthai0 libtiff4 libxcursor1 libxfixes3 libxft2 libxi6 libxinerama1 libxml2 libxrandr2 libxxf86dga1 libxxf86vm1 lprng lsb lsb-core lsb-cxx lsb-desktop lsb-graphics lsb-qt4 lsb-release mailx man-db mysql-common ncurses-term pax pciutils procps qt4-qtconfig rpm rsync x-ttcidfont-conf The following packages will be upgraded: apt apt-utils libsasl2-2 python-apt The following packages are RECOMMENDED but will NOT be installed: libsasl2-modules 4 packages upgraded, 71 newly installed, 0 to remove and 0 not upgraded. *** But then it doesn't install any new package at all: Need to get 35,6MB of archives. After unpacking 100,0MB will be used. The following packages have unmet dependencies: aptitude: Depends: libapt-pkg-libc6.3-6-3.11 which is a virtual package. 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)] Score is -30 Accept this solution? [Y/n/q/?] I really wonder why upgrading libsasl2-2 or any of the *apt* packages should have pulled in all those libraries? And if it did, why doesn't it say "keep ... at [uninstalled (now)]" for each of them? And if the NEW packages and the holding back are not related, then why on earth does dist-upgrade install new packages, without any already-installed package starting to depend on it? Pressing "o" at the prompt gives only information about the held back ones. If I press "y", oh wonder, it does not install 71 new packages... Regards, Frank -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6.3 0.6.46.4-0.1 Advanced front-end for dpkg ii libc6 2.5-11 GNU C Library: Shared libraries ii libgcc1 1:4.2-20070609-1 GCC support library ii libncursesw55.6-3Shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.0.17-2 type-safe Signal Framework for C++ ii libstdc++6 4.2-20070609-1 The GNU Standard C++ Library v3 Versions of packages aptitude recommends: pn aptitude-doc-en | aptitude-do (no description available) pn libparse-debianchangelog-perl (no description available) -- no debconf information -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
