Bug#757906: Dependency solution problems currently with gnuplog

[Anton Gladky]

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 at 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 at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers