David Kalnischkies wrote: > Bob Proulx wrote: > > # apt-get -o Debug::pkgProblemResolver=yes dist-upgrade > > Reading package lists... Done > > Building dependency tree > > Reading state information... Done > > Calculating upgrade... Starting pkgProblemResolver with broken count: 2 > > Starting 2 pkgProblemResolver with broken count: 2 > > I like to imagine that in the "problem resolver" two packages are put > into a cage and do a simple and clean fight to decide who can rule over > the other. On hell of a way to resolve your problems, isn't it? A very interesting way to look at things. I like it! :-) > > Investigating (0) libdb-dev [ amd64 ] < 5.1.7 -> 5.3.0 > ( libdevel ) > > Broken libdb-dev:amd64 Conflicts on libdb5.1-dev [ amd64 ] < 5.1.29-7 > ( libdevel ) > > Considering libdb5.1-dev:amd64 -1 as a solution to libdb-dev:amd64 -1 > > Holding Back libdb-dev:amd64 rather than change libdb5.1-dev:amd64 > > Two contenders: In the left corner: "libdb-dev" (the challenger) and in > the other "libdb5.1-dev". The "-1" next to each name signal the points > they got in their fight (Looks like they are not good fighters...). > As usual, in the case of a draw the challenger looses, so he has to hold > back with his wish to remove libdb5.1-dev. First case settled. So I see that the "-1" above is a total that reports the count of points that has accumulated. Both are equal so there is no winner. Is there an additional debug option to be able to report what points went into the -1 total? > > Investigating (0) libdb5.3-dev [ amd64 ] < none -> 5.3.28-3 > ( libdevel ) > > Broken libdb5.3-dev:amd64 Conflicts on libdb5.1-dev [ amd64 ] < 5.1.29-7 > ( libdevel ) > > Considering libdb5.1-dev:amd64 -1 as a solution to libdb5.3-dev:amd64 -1 > > Holding Back libdb5.3-dev:amd64 rather than change libdb5.1-dev:amd64 > > Next one up: "libdb5.3-dev" against "libdb5.1-dev". Again, not a good > fight, but "libdb5.1-dev" remains undefeated and "libdb5.3-dev" can't do > what it would have liked to: Remove libdb5.1-dev. Second case settled. The package strategy of having a meta-package depend upon a newer version of a versioned package is used often. But this case might be unusual in that (as you point out) it has Breaks and Conflicts to deal with requiring the removal of the previous versioned package. Most packages doing this strategy allow the versioned packages to be installed side by side. That is a key difference in understanding the difference here. > (don't think that libdb5.1-dev should have lost based on the fact that > two packages wanted it to be gone. Point-calculation is complicated, > but this is e.g. considered, so its a fair "win"). It would be interesting to be able to list out the points that went into the calculation of the -1 total. Is there a way to do that? > > The following packages have been kept back: > > libdb-dev > > So in the end, APT decides against upgrading "libdb-dev" as it would > mean that a package you have installed (libdb5.1-dev) is removed with > dubious benefits. Read: none at best as libdb5.3-dev can provide the > same features or at worst loosing features – like in this case the > potential that your mission critical compilation doesn't work anymore, > because 5.3 isn't 5.1. So, in other word: aptitude is a bit more relaxed > (in its default configuration) regarding breakage. You can like that or > you don't... I personally prefer apt logic, clean and simple to follow if > you understand the general idea. I can see the two different sides of view for this discussion. On the one side a working system is preserved to be working. And I don't have any complaints about the system functionality. It is working and is continuing to work. On the other side a Sid Unstable machine isn't as fully upgraded as one that would be if pristinely installed. If I were to build a new deb package on this system then it would build off of a library that isn't the latest. (Giving more credence to sbuild, pbuild, and other clean environment builders.) I am not complaining. I am just pointing out the obvious while understanding the issues involved. I was seeking understanding. I generally prefer using apt-get too. Most of the time it behaves better. > libdb is a bit special in that it provides versioned -dev packages > which can't be co-installed as well as an unversioned one. > Why that is the case, you are better of asking the maintainers... With the above information now known it does seem to be an unusual package strategy for this library. It would be useful if it were possible to know the details of what went into the -1 totals in the above. It would explain more. > Anyway, either the maintainers will change this (somehow I doubt it), > the situation will fix itself at the moment libdb5.1 leaves the archive > as this means it gets (even less) points db4.8 was removed from Sid Unstable on 2013-11-06 (Bug#728451). I think that db5.1 may remain in Sid for quite some time. > or someday around the end of this year a release critical bug will > be opened against apt asking for an explanation why apt "clearly > does the wrong thing here"(TM). Possible too. It does seem that apt-get might not be agressive enough at upgrading in this particular type of situation. However it does indicate this state. The admin is notified of the issue. The admin can take manual action to do the "Right Thing" here. It just doesn't do the Right Thing automatically. It doesn't do the wrong thing. It just isn't as nice as it could be. > (I am writing this mail mainly so I can point to it then, > claiming to be a big prophet. Wish me luck - or better don't.) Thank you very much for taking the time to explain these details to me. It was very helpful. Bob
Attachment:
signature.asc
Description: Digital signature