Bug#757906: Dependency solution problems currently with gnuplog

[Klaus Ethgen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello David,

thanks for your very, very great answer.

Am Sa den 16. Aug 2014 um 13:43 schrieb David Kalnischkies:
[Dependency resolving]
> Sounds easy, right?

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.

> > - 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?

I am fully with you. Thats the reason why I wrote "That would not be the
best solution".

> You have both installed, so you seem to want both after all???

Or maybe it was old dependencies. I, to be true, don't know.

> > - 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 ???).

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.

> 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.

The new versions, right.

> 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???).

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.

> 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.

:-D

> > 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???

Well, just some thoughts I had with that. I myself have only one
(private) system with SSD and the bug does not happens there.

> - in other words: Please don't try to invent arguments as it spoils
> the good arguments before???

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
- -- 
Klaus Ethgen                              http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen <Klaus at Ethgen.de>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQGcBAEBCgAGBQJT9xDKAAoJEKZ8CrGAGfasyDwMAMcSMuO7zUyyYvGQtDdmNCXh
7yUiytVtiVZA2QKRbxtT1nxBnTmuonyO3JS/HF9LZrasuPweRZOlsN3bdySpNv9S
iHCY/QFU6ozVG38JQlOsfjtchnbo1XBXUKxlmLHXTSxuMcPNXLENOhYatGmXuJXk
5+SlN01vfcxCwfO91Xc9xU3xI759GLXI3IFVYPDsLcyPCc32/Cdtg4fGTwyJNY7Z
3SfgwcX3VjaPYB9x3/oxxo5Vk6oeQOr36mR+M3lAmjEH0twTE9m2nVDLckbIs1Nu
EPSQxc1sPv3ZRdYT7uDxsQNALbgn2BqyXIKNaJ83DkdCfmzjUWlCiCmHRLFKwT5f
5NrvKp+qoy8zxUn4Aa//LGvPQHpN+ZtiXCK7b16/iSfXDYkTNMs9mQ2rx+XMRrX7
AkszQce/wlJyONwYPsuq/rPDwbcrdhiMZI0/khxpsqzrvqfGfzvddL4oM37Z4SZl
slszTPON/D3n+4kumDG07tM2WCHlPbRn9K96kl0olw==
=NY2T
-----END PGP SIGNATURE-----