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 <da...@kalnischkies.de>: > 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 > > -- > debian-science-maintainers mailing list > debian-science-maintainers@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
