Bug#757906: Dependency solution problems currently with gnuplog
On Sat, Aug 16, 2014 at 10:20:08PM +0200, Anton Gladky wrote: 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. Well, I don't want to be an inch pincher, but using Conflicts for this is forbidden by policy (second-last paragraph of §7.4 Conflicting binary packages) so technically an rc-bug, but if you really insist at least use Breaks as it is less demanding for the package manager. I don't see the problem this is trying to solve though. Sure, a user can install -nox and -x11 together and the -x11 binary can do the same as the -nox binary, so this will waste some diskspace if he does… so? Further more, I don't understand why -qt conflicts with -x11 as it is completely fine to have a multi-user system were some will like an -x11 frontend better than -qt or the other way around, but I know nothing about the packages in question, so I will shut up now and let people who know stuff do stuff. :) Best regards David Kalnischkies signature.asc Description: Digital signature
Bug#757906: Dependency solution problems currently with gnuplog
-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 installautoremove 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 kl...@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- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757906: Dependency solution problems currently with gnuplog
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 installautoremove 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 signature.asc Description: Digital signature
Bug#757906: Dependency solution problems currently with gnuplog
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 installautoremove 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-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble?
Bug#757906: Dependency solution problems currently with gnuplog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: apt Version: 1.0.6 Severity: normal 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. Now comes the problem. With any apt-get dist-upgrade, apt is installing the packages aglfn, gnuplot-data und gnuplot-tex (as they are in the dependencies of the packages version 4.6.5-10 but not as dependencies of version 4.6.5-6. The funny think is that I get informed with the same command that installs that packages, that they are going to get deinstalled with a autoremove as they are not needed. That game comes up now with every upgrade cycle (daily). 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. - - 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.) - - 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. 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. This problem will comes into sever state when gnuplot (in this case) with that version will be stable in future. It will end with systems not fully upgraded to newer stable releases. - -- Package-specific info: - -- apt-config dump -- APT ; APT::Architecture amd64; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends false; APT::Install-Suggests 0; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^firmware-linux.*; APT::NeverAutoRemove:: ^linux-firmware$; APT::NeverAutoRemove:: ^linux-image-3\.13\.11$; APT::NeverAutoRemove:: ^linux-image-3\.15\.6$; APT::NeverAutoRemove:: ^linux-headers-3\.13\.11$; APT::NeverAutoRemove:: ^linux-headers-3\.15\.6$; APT::NeverAutoRemove:: ^linux-image-extra-3\.13\.11$; APT::NeverAutoRemove:: ^linux-image-extra-3\.15\.6$; APT::NeverAutoRemove:: ^linux-signed-image-3\.13\.11$; APT::NeverAutoRemove:: ^linux-signed-image-3\.15\.6$; APT::NeverAutoRemove:: ^kfreebsd-image-3\.13\.11$; APT::NeverAutoRemove:: ^kfreebsd-image-3\.15\.6$; APT::NeverAutoRemove:: ^kfreebsd-headers-3\.13\.11$; APT::NeverAutoRemove:: ^kfreebsd-headers-3\.15\.6$; APT::NeverAutoRemove:: ^gnumach-image-3\.13\.11$; APT::NeverAutoRemove:: ^gnumach-image-3\.15\.6$; APT::NeverAutoRemove:: ^.*-modules-3\.13\.11$; APT::NeverAutoRemove:: ^.*-modules-3\.15\.6$; APT::NeverAutoRemove:: ^.*-kernel-3\.13\.11$; APT::NeverAutoRemove:: ^.*-kernel-3\.15\.6$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-3\.13\.11$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-3\.15\.6$; APT::NeverAutoRemove:: ^linux-tools-3\.13\.11$; APT::NeverAutoRemove:: ^linux-tools-3\.15\.6$; APT::VersionedKernelPackages ; APT::VersionedKernelPackages:: linux-image; APT::VersionedKernelPackages:: linux-headers; APT::VersionedKernelPackages:: linux-image-extra; APT::VersionedKernelPackages:: linux-signed-image; APT::VersionedKernelPackages:: kfreebsd-image; APT::VersionedKernelPackages:: kfreebsd-headers; APT::VersionedKernelPackages:: gnumach-image; APT::VersionedKernelPackages:: .*-modules; APT::VersionedKernelPackages:: .*-kernel; APT::VersionedKernelPackages:: linux-backports-modules-.*; APT::VersionedKernelPackages:: linux-tools; APT::Never-MarkAuto-Sections ; APT::Never-MarkAuto-Sections:: metapackages; APT::Never-MarkAuto-Sections:: restricted/metapackages; APT::Never-MarkAuto-Sections:: universe/metapackages; APT::Never-MarkAuto-Sections:: multiverse/metapackages; APT::Never-MarkAuto-Sections:: oldlibs; APT::Never-MarkAuto-Sections:: restricted/oldlibs; APT::Never-MarkAuto-Sections:: universe/oldlibs; APT::Never-MarkAuto-Sections:: multiverse/oldlibs; APT::Periodic ; APT::Periodic::Update-Package-Lists 1; APT::Periodic::Download-Upgradeable-Packages 0; APT::Periodic::AutocleanInterval 1; APT::Periodic::MaxAge 30; APT::Periodic::MinAge 2; APT::Periodic::MaxSize 500; APT::Update ; APT::Update::Pre-Invoke ; APT::Update::Pre-Invoke:: if [ -x /usr/bin/daptup ]; then /usr/bin/daptup --pre; fi; APT::Update::Post-Invoke ; APT::Update::Post-Invoke:: if [ -x /usr/bin/daptup ]; then /usr/bin/daptup --post; fi; APT::Update::Post-Invoke-Success ; APT::Update::Post-Invoke-Success:: test -x /usr/bin/apt-show-versions || exit 0 ; apt-show-versions -i; APT::Get ; APT::Get::Show-Upgraded true; APT::Get::Show-Versions true; APT::Get::Purge true; APT::Cache ; APT::Cache::AllVersions false; APT::Acquire ; APT::Acquire::Description de;
