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
