I have the both packages, gnuplot-nox and gnuplot-x11, installed with version 4.6.5-6. The new version of that packages are 4.6.5-10 but conflicting each other. Now comes the problem. With any "apt-get dist-upgrade", apt is installing the packages aglfn, gnuplot-data und gnuplot-tex (as they are in the dependencies of the packages version 4.6.5-10 but not as dependencies of version 4.6.5-6. The funny think is that I get informed with the same command that installs that packages, that they are going to get deinstalled with a autoremove as they are not needed. That game comes up now with every upgrade cycle (daily). I see two or tree solutions for this problem: - Just take only the installable packages in consideration when resolving dependencies. That would not update gnuplot-nox and/or gnuplot-x11 but would not install and deinstall the dependencies of newer package every time. - Pick one out of the conflicting packages to keep and upgrade and deinstall the other. That would be not the best solution but at least allows to update them. The user can choose afterwards to install the other package. (Maybe taking the one that has the least dependencies.) - Inform the user clearly _why_ they are not updated. At the moment it only shows that they have been kept back but not for what reason. With this packages it is just annoying and maybe is not good for SSDs as they would wear out. But for other packages that problem can get really problematic so I think it should be solved. This problem will comes into sever state when gnuplot (in this case) with that version will be stable in future. It will end with systems not fully upgraded to newer stable releases.
Control: reassign -1 gnuplot 4.6.5-10 This is the underlying problem, which is why I am reassigning to gnuplot so they can figure something out. Packages should have a clear upgrade path, period. This might be a bit more relaxed for testing/sid, but given that Debian has many derivatives (and users) basing on this as well, a good path would not hurt for them as well after all: We need them as testers, so we should treat well. ;) Further more, I don't see a file conflict between -nox and -x11, so I wonder why commit b5b3c3b37abb03029a22891fdb98b9e22ca00c41 readds it (wheezy has file conflicts and had replaces/conflicts). (what follows is an answer to the general points raised in the bugreport as well, mostly unrelated to the actual problem at hand) Sounds easy, right? You might realize though that you don't know if a package is installable without resolving its dependencies and even if each subtree is installable, doesn't mean that some subtrees do not require the removal of another subtree … … which apt really really really hates to do – so it usually doesn't – for good reason: How on earth should apt be able to decide for you if you want -x11 or -nox? You have both installed, so you seem to want both after all… Again, this sounds easy, but in practice it means that with the completion of this project we have created an artificial human-like intelligence (well, given that even I usually don't know why without a lot of debugging, probably well beyond human …). You can get a glimpse of this with -o Debug::pkgProblemResolver=1 and it will tell you in its strange way what you want to know, but only because this situation here is trivial as -x11 and -nox conflict explicitly. Now imagine a situation in which some obscure package on the 10th level in the tree makes a 2nd level or-group decision impossible… in an algorithm which is designed to decide once and never questions this decision again (as reconsidering means we are prune to run into an endless loop – in practice, we have some points where we carefully do backtracking, but that is hard…). Anyway, all three are generalisations of smaller bugs we already have reported in the BTS (multiple times) we are hopeful to tackle one at the time as time permits, so I hope you understand that I am not cloning or otherwise retaining this bugreport as a sort of never-closeable metabug. The thing with installing and also suggesting to autoremove them is e.g. something I am trying to hunt down at the moment. It works most of the time correctly (we have a test for this, so I am sure), but some special conditions seem to spoil it… I should really get an SSD, so that I might understand the constant fear of everyone with one that it could wear out, but I somehow doubt many people do an endless loop of install&autoremove cycles to make a considerable dent in this problem space… - in other words: Please don't try to invent arguments as it spoils the good arguments before… Best regards David Kalnischkies
Hi all, thanks David for your extended response! The problem is that I do not know, how to fix this problem properly. On some stage of gnuplot maintaining it was decided not to conflict -nox with others. But there is no need to keep -nox and -x11 together, because -x11 provides all functionality of -nox. There should not be any problems by Wheezy->Jessie migration what is the most important for us. Patches are always welcome. Cheers Anton 2014-08-16 14:43 GMT+02:00 David Kalnischkies <david@kalnischkies.de>:
Hello David, thanks for your very, very great answer. Am Sa den 16. Aug 2014 um 13:43 schrieb David Kalnischkies: [Dependency resolving] Well, I know what it is to resolve dependencies. I did create some solutions in the past that was heavily resolving dependencies. So I know that it is not an easy job. I am fully with you. Thats the reason why I wrote "That would not be the best solution". Or maybe it was old dependencies. I, to be true, don't know. Well, I don't think that it is this hard to print out the dependency tree just in conflict situation. (Nicely formated...) However, I did not have a peek into the internal structure in apt. The new versions, right. That's true. I would propose a shortest path resolving for such. As apt is asking the user anyway, it is with him to accept or decline the solution. With some more informations what triggers the decission it really would help the user (admin in this case) to resolve the problem by hand. :-D Well, just some thoughts I had with that. I myself have only one (private) system with SSD and the bug does not happens there. Sorry about, was not meant this way. When I will have some spare time I might peek into resolving code of apt once. Maybe I can bring some knowledge in. As I told, I have some experiences in creating resolvers. But I don't want to make any promise as I lag a bit on time. Regards Klaus
Well, I don't want to be an inch pincher, but using Conflicts for this is forbidden by policy (second-last paragraph of §7.4 Conflicting binary packages) so technically an rc-bug, but if you really insist at least use Breaks as it is less demanding for the package manager. I don't see the problem this is trying to solve though. Sure, a user can install -nox and -x11 together and the -x11 binary can do the same as the -nox binary, so this will waste some diskspace if he does… so? Further more, I don't understand why -qt conflicts with -x11 as it is completely fine to have a multi-user system were some will like an -x11 frontend better than -qt or the other way around, but I know nothing about the packages in question, so I will shut up now and let people who know stuff do stuff. :) Best regards David Kalnischkies