Bug#757906: Dependency solution problems currently with gnuplog

[David Kalnischkies]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20140816/39ae9dc8/attachment-0001.sig>