Control: reassign -1 gnuplot 4.6.5-10 On Tue, Aug 12, 2014 at 10:07:03AM +0100, Klaus Ethgen wrote: > 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. 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) > 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. 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 … > - 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.) … 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… > - 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. 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… > 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. 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
Attachment:
signature.asc
Description: Digital signature