Your message dated Wed, 9 Dec 2015 17:07:40 +0000 with message-id <CAPQ4b8=cir3lpsntndrwuv4g-rghcbfdja5xr0kxasjwuno...@mail.gmail.com> and subject line Re: aptitude: Aptitude makes the wrong choice when resolving conflict with alternative package has caused the Debian Bug report #540978, regarding aptitude: Aptitude makes the wrong choice when resolving conflict with alternative package 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.) -- 540978: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540978 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: aptitude Version: 0.4.11.11-1+b2 Severity: normal I have a metapackage josh-gui, which among other things depends on totem-xine and conflicts with totem-gstreamer. Various packages depend on totem-gstreamer | totem-xine, such as gnome-desktop-environment and totem-plugins. Whenever a new version of totem comes out, and I attempt to upgrade to it (usually by hitting + on the "video" section including totem-common, totem-xine, and totem-plugins), aptitude gets confused: it attempts to pull in totem-gstreamer (despite not needing it to satisfy any dependencies, with totem-xine already installed), and it then correctly concludes that it has broken josh-gui. Furthermore, to fix this brokenness, it initially proposes removing josh-gui; its *second* solution does the right thing by choosing *not* to install totem-gstreamer in the first place. - Josh Triplett -- Package-specific info: aptitude 0.4.11.11 compiled at Aug 3 2009 16:22:21 Compiler: g++ 4.3.3 Compiled against: apt version 4.8.0 NCurses version 5.7 libsigc++ version: 2.0.18 Ept support enabled. Current library versions: NCurses version: ncurses 5.7.20090803 cwidget version: 0.5.12 Apt version: 4.8.0 linux-vdso.so.1 => (0x00007fff47d40000) libapt-pkg-libc6.9-6.so.4.8 => /usr/lib/libapt-pkg-libc6.9-6.so.4.8 (0x00007fa8de04a000) libncursesw.so.5 => /lib/libncursesw.so.5 (0x00007fa8dddf9000) libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0x00007fa8ddbf4000) libcwidget.so.3 => /usr/lib/libcwidget.so.3 (0x00007fa8dd921000) libept.so.0 => /usr/lib/libept.so.0 (0x00007fa8dd6a8000) libxapian.so.15 => /usr/lib/libxapian.so.15 (0x00007fa8dd352000) libz.so.1 => /usr/lib/libz.so.1 (0x00007fa8dd13b000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007fa8dcf20000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fa8dcc12000) libm.so.6 => /lib/libm.so.6 (0x00007fa8dc98f000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fa8dc775000) libc.so.6 => /lib/libc.so.6 (0x00007fa8dc424000) libutil.so.1 => /lib/libutil.so.1 (0x00007fa8dc221000) libdl.so.2 => /lib/libdl.so.2 (0x00007fa8dc01d000) /lib64/ld-linux-x86-64.so.2 (0x00007fa8de30f000) Terminal: xterm $DISPLAY is set. `which aptitude`: /usr/bin/aptitude aptitude version information: aptitude linkage: -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6. 0.7.22.2 Advanced front-end for dpkg ii libc6 2.9-23 GNU C Library: Shared libraries ii libcwidget3 0.5.12-4 high-level terminal interface libr ii libept0 0.5.27 High-level library for managing De ii libgcc1 1:4.4.1-1 GCC support library ii libncursesw5 5.7+20090803-1 shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.0.18-2 type-safe Signal Framework for C++ ii libstdc++6 4.4.1-1 The GNU Standard C++ Library v3 ii libxapian15 1.0.14-2 Search engine library ii zlib1g 1:1.2.3.3.dfsg-15 compression library - runtime Versions of packages aptitude recommends: pn aptitude-doc-en | aptitude-do <none> (no description available) ii libparse-debianchangelog-perl 1.1.1-2 parse Debian changelogs and output Versions of packages aptitude suggests: pn debtags <none> (no description available) pn tasksel <none> (no description available) -- no debconf information
--- End Message ---
--- Begin Message ---2015-12-09 16:53 GMT+00:00 Josh Triplett <[email protected]>: > On Wed, Dec 09, 2015 at 03:50:34PM +0000, Manuel A. Fernandez Montecelo wrote: >> Control: tags -1 + moreinfo >> >> >> Hi Josh, >> >> 2009-08-11 04:02 Josh Triplett: >> >Package: aptitude >> >Version: 0.4.11.11-1+b2 >> >Severity: normal >> > >> >I have a metapackage josh-gui, which among other things depends on >> >totem-xine and conflicts with totem-gstreamer. Various packages depend >> >on totem-gstreamer | totem-xine, such as gnome-desktop-environment and >> >totem-plugins. Whenever a new version of totem comes out, and I attempt >> >to upgrade to it (usually by hitting + on the "video" section including >> >totem-common, totem-xine, and totem-plugins), aptitude gets confused: it >> >attempts to pull in totem-gstreamer (despite not needing it to satisfy >> >any dependencies, with totem-xine already installed), and it then >> >correctly concludes that it has broken josh-gui. Furthermore, to fix >> >this brokenness, it initially proposes removing josh-gui; its *second* >> >solution does the right thing by choosing *not* to install >> >totem-gstreamer in the first place. >> >> Have you seen this behaviour recently, with this package of yours or >> others? >> >> The resolution system changed a lot in the years after this bug report, >> specially with 0.6. I could attempt to reproduce a similar case with >> other packages (totem-xine and -gstreamer are not in unstable now), but >> if you continue to have a similar set-up it would be quicker / more >> reliable to confirm if the behaviour it's still happening as you saw it >> in the past. > > I still see dependency resolution issues arise fairly often, where > aptitude wants to remove half the world rather than making what seems > like a more obvious choice. This specific situation went away when > totem-xine did, though. Yes, there are still many dependency resolution issues reported in more recent times, and that I experience every other day, especially some that suggest to remove many (e.g. all KDE) rather than upgrade one package (which in principle are not related to the kind of conflicts mentioned in your original report). > Probably better to report new issues for new dependency resolution > problems that apply to current Debian, rather than attempting to > repurpose this six-year-old bug. OK, I will close this one then. Please open a new one specially if you see a similar situation involving package alternatives and conflicts, similar to the case originally reported. (Others are also OK, but bad suggestions in the resolution are so common that probably there will be reportes and with some duplicates already). 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
