Your message dated Mon, 1 Dec 2014 01:10:00 +0100
with message-id <[email protected]>
and subject line Re: [Aptitude-devel] Bug#771605: aptitude: Does not resolve
file conflicts
has caused the Debian Bug report #771605,
regarding aptitude: Does not resolve file conflicts
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.)
--
771605: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771605
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: aptitude
Version: 0.6.8.2-1ubuntu4
Severity: important
When upgrading, if a file moved from package to package, conflicts often
occur. This can be resolved by installing packages in a particular
order, which Aptitude should do automatically but doesn’t.
For example, suppose first-package=1.0 and second-package=1.0 are
installed, with a certain file belonging to the first one. But for v2.0 of
the packages, the file is in the second package instead. Upgrading the
packages is only possible starting with the one with the file, so the
file is temporarily removed from the system altogether, then
second-package=2.0 kicks in and reinstates the file. If Aptitude happens
to start with the wrong one, dpkg will fail and the entire upgrade will
fail, leaving the user to resolve it manually.
This happens with KDE packages, at least in Ubuntu, all the time. For the
average user, the problem is hard to diagnose and fix, and causes
a failure of the entire upgrade, possibly leaving the system in an
inconsistent state.
The problem boils down to particular versions of particular packages
having conflicts that are not immediately visible to Aptitude. Is it
possible for Aptitude, upon encountering such an error from dpkg, to
mark down the conflict and re-run the resolution algorithm? Or possibly
look through the lists of files while resolving dependencies if that’s
not too resource-intensive?
While an argument can be made that the fault lies with the repository
that has conflicting packages not marked as such, this is still a
hard-to-resolve issue that Aptitude is in position to prevent,
therefore I suggest it should do so.
-- Package-specific info:
Terminal: xterm
$DISPLAY is set.
which aptitude: /usr/bin/aptitude
aptitude version information:
aptitude 0.6.8.2 compiled at Feb 17 2014 23:57:51
Compiler: g++ 4.8.2
Compiled against:
apt version 4.12.0
NCurses version 5.9
libsigc++ version: 2.2.10
Ept support enabled.
Gtk+ support disabled.
Qt support disabled.
Current library versions:
NCurses version: ncurses 5.9.20140712
cwidget version: 0.5.16
Apt version: 4.12.0
aptitude linkage:
linux-gate.so.1 => (0xb77a5000)
libapt-pkg.so.4.12 => /usr/lib/i386-linux-gnu/libapt-pkg.so.4.12
(0xb71e1000)
libncursesw.so.5 => /lib/i386-linux-gnu/libncursesw.so.5 (0xb71a6000)
libtinfo.so.5 => /lib/i386-linux-gnu/libtinfo.so.5 (0xb7182000)
libsigc-2.0.so.0 => /usr/lib/i386-linux-gnu/libsigc-2.0.so.0
(0xb717c000)
libcwidget.so.3 => /usr/lib/libcwidget.so.3 (0xb7079000)
libept.so.1.aptpkg4.12 =>
/usr/lib/i386-linux-gnu/libept.so.1.aptpkg4.12 (0xb7022000)
libxapian.so.22 => /usr/lib/sse2/libxapian.so.22 (0xb6e28000)
libsqlite3.so.0 => /usr/lib/i386-linux-gnu/libsqlite3.so.0 (0xb6d51000)
libboost_iostreams.so.1.54.0 =>
/usr/lib/i386-linux-gnu/libboost_iostreams.so.1.54.0 (0xb6d39000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb6d1c000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb6c27000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb6be1000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb6bc2000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb6a14000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb6a0f000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb69f5000)
libbz2.so.1.0 => /lib/i386-linux-gnu/libbz2.so.1.0 (0xb69e2000)
liblzma.so.5 => /lib/i386-linux-gnu/liblzma.so.5 (0xb69bb000)
libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xb69b5000)
/lib/ld-linux.so.2 (0xb77a6000)
-- System Information:
Debian Release: jessie/sid
APT prefers utopic-updates
APT policy: (500, 'utopic-updates'), (500, 'utopic-security'), (500, 'utopic')
Architecture: i386 (i686)
Kernel: Linux 3.13.0-36-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages aptitude depends on:
ii aptitude-common 0.6.8.2-1ubuntu4
ii libapt-pkg4.12 1.0.9.2ubuntu2
ii libboost-iostreams1.54.0 1.54.0-4ubuntu3.1
ii libc6 2.19-10ubuntu2
ii libcwidget3 0.5.16-3.5ubuntu1
ii libept1.4.12 1.0.12
ii libgcc1 1:4.9.1-16ubuntu6
ii libncursesw5 5.9+20140712-2ubuntu1
ii libsigc++-2.0-0c2a 2.2.10-0.2ubuntu2
ii libsqlite3-0 3.8.6-1
ii libstdc++6 4.9.1-16ubuntu6
ii libtinfo5 5.9+20140712-2ubuntu1
ii libxapian22 1.2.18-1ubuntu1
Versions of packages aptitude recommends:
ii apt-xapian-index 0.45ubuntu4
ii libparse-debianchangelog-perl 1.2.0-1.1
ii sensible-utils 0.0.9
Versions of packages aptitude suggests:
pn aptitude-doc-en | aptitude-doc <none>
ii debtags 1.12ubuntu2
ii tasksel 2.88ubuntu15
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi,
Roman Odaisky wrote:
> Package: aptitude
> Version: 0.6.8.2-1ubuntu4
> Severity: important
>
> When upgrading, if a file moved from package to package, conflicts often
> occur. This can be resolved by installing packages in a particular
> order, which Aptitude should do automatically but doesn’t.
Does this happen with apt-get, too?
Because that is usually a bug in the affected packages and not in the
package.
> For example, suppose first-package=1.0 and second-package=1.0 are
> installed, with a certain file belonging to the first one. But for v2.0 of
> the packages, the file is in the second package instead. Upgrading the
> packages is only possible starting with the one with the file, so the
> file is temporarily removed from the system altogether, then
> second-package=2.0 kicks in and reinstates the file. If Aptitude happens
> to start with the wrong one, dpkg will fail and the entire upgrade will
> fail, leaving the user to resolve it manually.
Does second-package have according Breaks and Replaces headers against
first-package?
If not, it's clearly a bug in second-package.
> This happens with KDE packages, at least in Ubuntu, all the time.
So why are you reporting this bug in Debian and not in Ubuntu? The
version you gave is an Ubuntu version...
> The problem boils down to particular versions of particular packages
> having conflicts that are not immediately visible to Aptitude.
Then it's clearly a bug in those packages. Because aptitude shows
Breaks, Replaces and Conflicts headers.
> Is it possible for Aptitude, upon encountering such an error from
> dpkg, to mark down the conflict and re-run the resolution algorithm?
> Or possibly look through the lists of files while resolving
> dependencies if that’s not too resource-intensive?
No, that's what Breaks and Replaces headers are for.
> While an argument can be made that the fault lies with the repository
> that has conflicting packages not marked as such,
Not in the repository but in the packages in this repository.
> this is still a hard-to-resolve issue that Aptitude is in position
> to prevent, therefore I suggest it should do so.
It is not in the positition to do so -- as is no other high-level
package manager.
Regards, Axel
--
,''`. | Axel Beckert <[email protected]>, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
`- | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
--- End Message ---
_______________________________________________
Aptitude-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
