Bug#519893: aptitude: aptitude attempts to resolve unmet dependencies by upgrading a package with itself
Control: severity -1 wishlist Control: tags -1 + wontfix Control: retitle -1 aptitude: support for same package name and version in different repositories but different content Hi, As the maintainer said, all of the main Debian packaging tools, dpkg, apt and aptitude, decide on versions to install and what's newest based on comparing package versions (see dpkg --compare-versions). Se also #737085 for a recent example with apt of how things go wrong because of this, even with quite skilled developers very familiar with the system try to bootstrap a new architecture. So having different packages in different repositories with the same name and version is not something that the tools are designed/prepared to handle nicely, so I don't think that this request will ever be addressed. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519893: aptitude: aptitude attempts to resolve unmet dependencies by upgrading a package with itself
On Wed, 18 Mar 2009 15:53:49 +0100, Daniel Burrows dburr...@debian.org wrote: When you run dist-upgrade, what happens is: (1) aptitude sees a newer version of libgtk2.0-0 and marks it for an upgrade. (that would be the version in the unstable archive) You meant pidgin, not libgtk2.0-0? It's about versions of pidgin. Yes, here is when it first goes wrong, because pidgin 2.5.5-1 in unsable isn't any newer than my 2.5.5-1. (2) aptitude notices, rightly, that the version of gtk2.0-0 on your computer doesn't have dependency problems, and offers to switch to it instead. (these sidegrades are lumped together with upgrades in the display, probably that's a bug) Well, why did it think that any package was broken in the first place? If my 2.5.5-1 really came from unstable, it would be broken, but the one I have isn't. If aptitude looked into the /var/lib/dpkg/status at the Depends: field under Package: pidgin, it would have seen that the pidgin I have has all of its dependencies satisfied. Nothing is broken, so nothing needs to be fixed. (3) Because libapt is confused about how many gtks there are and which one is newer, when aptitude asks it to make 2.5.5-1 (from your local repository) the current version, it decides it has to fetch and install a new version. (4) But of course there's still a newer version in unstable, so when you run dist-upgrade we go back to (1). I'm not quite sure about (3), i.e., why you're *actually* getting a new version fetched. The easiest way for you to solve your problem is to just change the version number on your package to something larger than the unstable version (e.g., to something like 2.0.0-1.1~localrebuild). Sure, I can work around it in several ways, but I think the bug(s) should be fixed. All the apt tools and libraries tend to assume that different packages have different version numbers and you'll see odd behavior if you have distinct packages that have the same version number. I still think that for installed packages apt should believe what /var/lib/dpkg/status stays more than anything else, at least when deciding whether something is currently broken. 4. aptitude shows NULL for the repository of the proposed package. I'm guessing your local repository doesn't have a Release file that states what its archive name is. It would probably be better to display no archive information in this case, though! That's right, no Release file there. This issue is minor, of course, but still a bug. Should this bug report be split into several issues? -- Alexey Feldgendler ale...@feldgendler.ru [ICQ: 115226275] http://feldgendler.livejournal.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519893: aptitude: aptitude attempts to resolve unmet dependencies by upgrading a package with itself
On Sun, Mar 15, 2009 at 11:49:40PM +0100, Alexey Feldgendler x...@pita.feldgendler.ru was heard to say: 1. apt-cache doesn't seem to realize that the 2.5.5-1 at file: and the one currently installed are the same. (Still doesn't realize even after aptitude has “upgraded” it with itself.) I think this is the root of all your problems. When you run dist-upgrade, what happens is: (1) aptitude sees a newer version of libgtk2.0-0 and marks it for an upgrade. (that would be the version in the unstable archive) (2) aptitude notices, rightly, that the version of gtk2.0-0 on your computer doesn't have dependency problems, and offers to switch to it instead. (these sidegrades are lumped together with upgrades in the display, probably that's a bug) (3) Because libapt is confused about how many gtks there are and which one is newer, when aptitude asks it to make 2.5.5-1 (from your local repository) the current version, it decides it has to fetch and install a new version. (4) But of course there's still a newer version in unstable, so when you run dist-upgrade we go back to (1). I'm not quite sure about (3), i.e., why you're *actually* getting a new version fetched. The easiest way for you to solve your problem is to just change the version number on your package to something larger than the unstable version (e.g., to something like 2.0.0-1.1~localrebuild). All the apt tools and libraries tend to assume that different packages have different version numbers and you'll see odd behavior if you have distinct packages that have the same version number. 4. aptitude shows NULL for the repository of the proposed package. I'm guessing your local repository doesn't have a Release file that states what its archive name is. It would probably be better to display no archive information in this case, though! Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519893: aptitude: aptitude attempts to resolve unmet dependencies by upgrading a package with itself
Package: aptitude
Version: 0.4.11.11-1
Severity: important
I run testing, but need pidgin 2.5.5-1 (currently in unstable). To
avoid it pulling lots of unstable libraries, I rebuilt pidgin with
libraries from testing, put the binary package into my local file:
repository and installed. Now aptitude offers me the following every
time I run dist-upgrade:
$ sudo aptitude dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
The following packages are BROKEN:
pidgin (D: libgtk2.0-0)
1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 702kB of archives. After unpacking 101kB will be used.
The following packages have unmet dependencies:
pidgin: Depends: libgtk2.0-0 (= 2.14.0) but 2.12.12-1 is installed.
The following actions will resolve these dependencies:
Upgrade the following packages:
pidgin [2.5.5-1 (now) - 2.5.5-1 (NULL)]
Score is 80
Accept this solution? [Y/n/q/?]
Note the NULL. If I agree to this, aptitude gets the package from
the local repository (exactly the one I currently have) and reinstalls
it, which, of course, doesn't improve the situation, and on the next
run dist-upgrade isn't any happier.
My homemade pidgin 2.5.5-1 depends on libgtk2.0-0 (= 2.12.0), which
is satisfied.
My apt.conf:
APT {
Default-Release testing;
Cache-Limit 26777216;
};
Aptitude {
CmdLine::Show-Deps true;
Autoclean-After-Update true;
Parse-Description-Bullets true;
};
No preferences file.
Details on pidgin versions:
$ apt-cache policy pidgin
pidgin:
Installed: 2.5.5-1
Candidate: 2.5.5-1
Version table:
2.5.5-1 0
500 http://ftp.no.debian.org unstable/main Packages
2.5.5-1 0
500 file: ./ Packages
*** 2.5.5-1 0
100 /var/lib/dpkg/status
2.5.4-2 0
990 http://ftp.no.debian.org testing/main Packages
There are several problems here:
1. apt-cache doesn't seem to realize that the 2.5.5-1 at file: and the
one currently installed are the same. (Still doesn't realize even
after aptitude has “upgraded” it with itself.)
2. aptitude thinks that pidgin is broken because 2.5.5-1 in unstable
depends on a newer libgtk2.0-0, even though the bastard 2.5.5-1 I
actually have is happy with my libgtk2.0-0 from testing.
3. aptitude tries to resolve the unmet dependency by upgrading to
exactly what I currently have.
4. aptitude shows NULL for the repository of the proposed package.
-- Package-specific info:
aptitude 0.4.11.11 compiled at Nov 20 2008 04:02:44
Compiler: g++ 4.3.2
Compiled against:
apt version 4.6.0
NCurses version 5.6
libsigc++ version: 2.0.18
Ept support enabled.
Current library versions:
NCurses version: ncurses 5.7.20090228
cwidget version: 0.5.12
Apt version: 4.6.0
linux-gate.so.1 = (0xb7ef4000)
libapt-pkg-libc6.7-6.so.4.6 = /usr/lib/libapt-pkg-libc6.7-6.so.4.6
(0xb7e26000)
libncursesw.so.5 = /lib/libncursesw.so.5 (0xb7de8000)
libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0 (0xb7de1000)
libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0xb7d1d000)
libept.so.0 = /usr/lib/libept.so.0 (0xb7c59000)
libxapian.so.15 = /usr/lib/libxapian.so.15 (0xb7b01000)
libz.so.1 = /usr/lib/libz.so.1 (0xb7aec000)
libpthread.so.0 = /lib/i686/cmov/libpthread.so.0 (0xb7ad3000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0xb79e4000)
libm.so.6 = /lib/i686/cmov/libm.so.6 (0xb79be000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xb79b1000)
libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb785)
libutil.so.1 = /lib/i686/cmov/libutil.so.1 (0xb784c000)
libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb7847000)
/lib/ld-linux.so.2 (0xb7ef5000)
Terminal: xterm
$DISPLAY is set.
`which aptitude`: /usr/bin/aptitude
aptitude version information:
aptitude linkage:
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-686 (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/bash
Versions of packages aptitude depends on:
ii apt [libapt-pkg-libc6. 0.7.20.2 Advanced front-end for dpkg
ii libc6 2.9-4 GNU C Library: Shared libraries
ii libcwidget30.5.12-4 high-level terminal interface libr
ii libept00.5.26High-level library for managing De
ii libgcc11:4.3.3-3 GCC support library
ii libncursesw5 5.7+20090228-1shared libraries for terminal hand
ii libsigc++-2.0-0c2a 2.0.18-2 type-safe Signal Framework for C++
ii libstdc++6 4.3.3-3 The GNU Standard C++ Library v3
ii libxapian151.0.10-2 Search engine library
ii zlib1g
