Bug#645412: cupt: Pin from apt-listbugs does not prevent package install/upgrade
Hi James, # cat /etc/apt/preferences Explanation: Pinned by apt-listbugs at Mon Oct 17 20:51:13 + 2011 Explanation: #615671: derivations: ftbfs with gcc-4.5 Package: derivations Pin: version * Pin-Priority: -3 As I understand, this is now officially implemented in apt-listbugs since 2012, and such low pins should prevent installations/upgrades of such pinned packages in Cupt unless they are unconditionally (or almost so [1]) requested. If that's the case, would you say I can close this bug now? We had a useful discussion with Francesco about possible future improvements here in the thread, but I think if we want to follow up on it I'll just open a new bug with a link to this one. [1] i.e. are absolute dependencies of something that is unconditionally requested, or are the only alternative to something really bad like removing essential packages or doing a bunch of downgrades. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645412: cupt: Pin from apt-listbugs does not prevent package install/upgrade
Hi Eugene! :-) On Tue, 13 Mar 2012 10:15:02 +0200 Eugene V. Lyubimkin wrote: [...] # cat /etc/apt/preferences Explanation: Pinned by apt-listbugs at Mon Oct 17 20:51:13 + 2011 Explanation: #615671: derivations: ftbfs with gcc-4.5 Package: derivations Pin: version * Pin-Priority: -3 As I understand, this is now officially implemented in apt-listbugs since 2012 Yes, I confirm that this is implemented in apt-listbugs, starting from version 0.1.6 ... Bye! -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpszQBjdzptr.pgp Description: PGP signature
Bug#645412: cupt: Pin from apt-listbugs does not prevent package install/upgrade
On Mon, 24 Oct 2011 10:10:10 +0300 Eugene V. Lyubimkin wrote: [...] The user should have (approximately) equivalent pins for both package managers. That's impossible if there are different pin priority systems. Well, but I hope there will be a way to tell cupt that: (A) version v1 of package P1 (which *is* currently installed) must not be upgraded (B) package P2 (which is currently *not* installed) must not be installed, whatever version is considered These are the basic rules that apt-listbugs injects into the apt pinning preferences. If there's a way to express such rules for cupt, then apt-listbugs will be able to be useful for cupt users. If not, then I will have to document that cupt is not fully supported by apt-listbugs and that cupt users should not expect apt-listbugs to work properly for them... As I said above, I am under the impression that apt-listbugs needs to *simultaneously* take care of each different scheme that must be supported. Currently, only one scheme is supported and everything is simple. Adding support for a second scheme requires code which is able to figure out how to handle weird situations that may arise when the two configuration files disagree on something. I was under impression that it's possible not to mix modes. Different schemes are inconsistent from the very beginning, they disagree on almost everything even if there would be no configuration files. I imagined it as 'if apt is installed, run in apt mode, forget about any non-apt schemes as if they don't exist', 'if say (cupt) is installed, run in cupt mode, forget about any non-cupt schemes as if they don't exist'. I think that the condition apt is installed is satisfied on almost any Debian box... I tried $ aptitude -s --purge-unused install apt_ aptitude_ cupt It said that 14 packages need to be removed and 6 recommendations need to be broken, in order to do this. Even reportbug depends on apt... This may of course change in the future, but I am under the impression that you'll still find apt installed on most Debian boxes for quite some time. Moreover, the condition cupt is installed does not necessarily mean that the system administrator regularly uses cupt to manage packages. I don't think that apt-listbugs can figure out whether it should deal with apt pinning preferences or with cupt pinning preferences. Hence, if there are two distinct pinning preferences schemes, apt-listbugs should try to *simultaneously* deal with both of them (if at all possible). Finally, even if we find a way to have apt-listbugs figure out which scheme it should use, there is always the possible scenario of a user switching from apt(itude) to cupt or vice-versa. That user should not lose previously set pinning preferences! [...] For the design point of view, it could be so that utilities like apt-listbugs work with the own state file with an own format in a package-manager-agnostic way, and for each package manager there is a tiny submodule which converts that file/data to a package-manager-specific configuration file every time the state file/data changes. For that to work, utilities should not change its behavior depending on the other (user) preferences, which I believe would be better. But that's my humble opinion. If I understand correctly, you are saying that apt-listbugs should generate rules (such as A and B above) in a package-manager-agnostic format and then convert them into package-manager-specific forms. I am not sure that this could work well: what if a user manually modifies the package-manager-specific configuration, without updating the package-manager-agnostic configuration accordingly? apt-listbugs would begin working with a distorted vision of the actual package manager configuration... -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpQ6kX8NPduU.pgp Description: PGP signature
Bug#645412: cupt: Pin from apt-listbugs does not prevent package install/upgrade
Hi Francesco, On 2011-10-29 18:33, Francesco Poli wrote: [...] Well, but I hope there will be a way to tell cupt that: (A) version v1 of package P1 (which *is* currently installed) must not be upgraded (B) package P2 (which is currently *not* installed) must not be installed, whatever version is considered Yes, there will be. Again, user will be able to override that, but then he/she will know what that may lead to. I think that the condition apt is installed is satisfied on almost any Debian box... Yes. Moreover, the condition cupt is installed does not necessarily mean that the system administrator regularly uses cupt to manage packages. However, this argument works in both directions: there are people (as in =1 :)) who have apt installed but don't use it to manage packages. I don't think that apt-listbugs can figure out whether it should deal with apt pinning preferences or with cupt pinning preferences. Hence, if there are two distinct pinning preferences schemes, apt-listbugs should try to *simultaneously* deal with both of them (if at all possible). I don't think it will be possible to deal with more than one scheme simultaneously unless apt-listbugs decide to drop any feedback checks (i.e. parsing other user preferences). That's why I imagined it as 'run the logic 2 times'. Finally, even if we find a way to have apt-listbugs figure out which scheme it should use, there is always the possible scenario of a user switching from apt(itude) to cupt or vice-versa. That user should not lose previously set pinning preferences! This would not be a case if apt-listbugs don't select a scheme to use but just run for every installed one. That would be usually 1 and in rare cases 2. But apparently you have some reason to not plan it this way. If I understand correctly, you are saying that apt-listbugs should generate rules (such as A and B above) in a package-manager-agnostic format and then convert them into package-manager-specific forms. Not like should be, just like could be, if we didn't have the high-level package manager monopoly. Yes, that's what I meant. I am not sure that this could work well: what if a user manually modifies the package-manager-specific configuration, without updating the package-manager-agnostic configuration accordingly? In that hypothetical scenario user would have a generated file like '/etc/apt/preferences.d/05apt-listbugs' with a first line, say, -8- # DO NOT EDIT, this file is auto-generated by apt-listbugs -8- If he still decides to edit it, well, he/she was warned. And apt-listbugs would regenerate the file after the every run anyway. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645412: cupt: Pin from apt-listbugs does not prevent package install/upgrade
In the concept I have in the mind all pin stanzas will not be final, so I think this check can be totally disabled in cupt mode. This looks problematic to me. I mean: I don't think that apt-listbugs should have distinct modes depending on the package manager the user wants to use. [...] But, obviously, the primary goal is supporting apt(itude). It's *apt*-listbugs, after all! Makes sense. The user should have (approximately) equivalent pins for both package managers. That's impossible if there are different pin priority systems. As I said above, I am under the impression that apt-listbugs needs to *simultaneously* take care of each different scheme that must be supported. Currently, only one scheme is supported and everything is simple. Adding support for a second scheme requires code which is able to figure out how to handle weird situations that may arise when the two configuration files disagree on something. I was under impression that it's possible not to mix modes. Different schemes are inconsistent from the very beginning, they disagree on almost everything even if there would be no configuration files. I imagined it as 'if apt is installed, run in apt mode, forget about any non-apt schemes as if they don't exist', 'if say (cupt) is installed, run in cupt mode, forget about any non-cupt schemes as if they don't exist'. It's not much lack of willingness to implement the changes, even though I may admit that time is a bit scarce down here, and I would prefer to consume it in fixing apt-listbugs own bugs, rather than in adding code that could create more problems than the ones it is intended to solve... Of course. I understand your position. Things will don't change until the archive freeze, let's see if I can figure something by that time. For the design point of view, it could be so that utilities like apt-listbugs work with the own state file with an own format in a package-manager-agnostic way, and for each package manager there is a tiny submodule which converts that file/data to a package-manager-specific configuration file every time the state file/data changes. For that to work, utilities should not change its behavior depending on the other (user) preferences, which I believe would be better. But that's my humble opinion. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645412: cupt: Pin from apt-listbugs does not prevent package install/upgrade
On Sun, 16 Oct 2011 17:12:43 +0300 Eugene V. Lyubimkin wrote: [...] On 2011-10-16 12:35, Francesco Poli wrote: [...] Mh... This looks like much more work than it would appear at a first glance... :-( Indeed I was too optimistic. Still, (A) it has to check whether a given package is already pinned in /etc/apt/preferences, in order to make the interactive command-menu work correctly In the concept I have in the mind all pin stanzas will not be final, so I think this check can be totally disabled in cupt mode. This looks problematic to me. I mean: I don't think that apt-listbugs should have distinct modes depending on the package manager the user wants to use. What if the user wants to use apt(itude) for some tasks and cupt for other ones? Or else (more common scenario, I think), what if the user uses apt(itude) and then decides to switch to cupt, and maybe later decides to switch back to apt(itude)? Or vice-versa? The user should have (approximately) equivalent pins for both package managers. Hence, apt-listbugs should try hard to generate and manipulate pin preferences that cause equivalent effects on both apt(itude) and cupt. Clearly, as long as cupt tries hard to share pin preferences with apt(itude), this is automatic and requires almost no additional actions from apt-listbugs. On the other hand, if cupt begins to use a distinct configuration file with different syntax and semantics, apt-listbugs will have to take care of both configuration files and figure out how to reconcile possible inconsistencies between them... The other possible strategy is to explicitly document that cupt is not supported and may fail to work well with apt-listbugs: I would *not* be happy to conclude that there's no other choice than this. I would love supporting cupt as far as possible. But, obviously, the primary goal is supporting apt(itude). It's *apt*-listbugs, after all! [...] But what about (A)? What if a package is pinned for Apt, but not for Cupt? Or vice-versa? Please remember that configuration files may be edited by hand by the (super-)user, hence it may always happen that a package is pinned for one package manager, but not for the other one... That's a hardest part I guess. I'd suggest not to mix different schemes and run the package manager part two times for each mode (if both are installed; if some of them is not installed, don't call the function with respective parameters). As I said above, I am under the impression that apt-listbugs needs to *simultaneously* take care of each different scheme that must be supported. Currently, only one scheme is supported and everything is simple. Adding support for a second scheme requires code which is able to figure out how to handle weird situations that may arise when the two configuration files disagree on something. [...] Back to the my proposal, indeed it requires more work that I thought, and I will understand if you won't want to implement the changes. It's not much lack of willingness to implement the changes, even though I may admit that time is a bit scarce down here, and I would prefer to consume it in fixing apt-listbugs own bugs, rather than in adding code that could create more problems than the ones it is intended to solve... It's not much lack of willingness to implement the changes, I was saying, it's more a matter of understanding if and how the whole thing can be done properly. Thanks for consideration in any case. You're welcome! :-) -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp4gC2DBJtC0.pgp Description: PGP signature
Bug#645412: cupt: Pin from apt-listbugs does not prevent package install/upgrade
On 2011-10-19 00:42, Francesco Poli wrote: Good, I've just pushed this modification to the apt-listbugs public git repository: see http://anonscm.debian.org/gitweb/?p=apt-listbugs/apt-listbugs.git;a=commitdiff;h=c7561047b211039c5d12e0006fd3af7a16d98ea6 You may therefore consider this modification as pending (that is to say, it will be present in the next upload). Thanks! As far as the rest of message http://bugs.debian.org/645412#32 is concerned, I still have to read it fully and think about your proposal. I hope I manage to find the time soon... ;-) Ack. Only one new addition to that is I decided to not push the change to upcoming stable release to have more time to design and test it, and also to not cause rush for anyone included myself (and you, if you decide to follow the changes) before archive freeze. Will create a long-lived branch instead. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645412: cupt: Pin from apt-listbugs does not prevent package install/upgrade
Hi Francesco, On 2011-10-17 23:36, Francesco Poli wrote: However, cupt happily goes on and attempts to install derivations, until apt-listbugs kicks in and warns the user (again!) that there's a bug: [...] If I recall correctly one conversation I had with you (Eugene) back on January 2010, this behavior is intentional. Only automatic installations of the low Pin-Priority package (as recommendations, or dependencies with alternatives, for instance) are prevented by cupt. The explicit request to install the low Pin-Priority package will be honored, no matter how low the Pin-Priority is. Exactly, with one remark that even for soft dependencies or alternatives it's not absolutely prevented, but for example they may be suggested if user explicitly rejects all better solutions. I actually like this behavior more than apt-based' package manager ones'. One more warning is maybe worth implementing in the user interface, but that's it. But I am biased, of course. Assuming that this is true and confirmed, is the modification of apt-listbugs (so that it uses -3 instead of -40 as Pin-Priority to prevent the installation of a package) still useful? As for me -- yes. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645412: cupt: Pin from apt-listbugs does not prevent package install/upgrade
On Tue, 18 Oct 2011 10:36:13 +0300 Eugene V. Lyubimkin wrote: [...] On 2011-10-17 23:36, Francesco Poli wrote: [...] Assuming that this is true and confirmed, is the modification of apt-listbugs (so that it uses -3 instead of -40 as Pin-Priority to prevent the installation of a package) still useful? As for me -- yes. Good, I've just pushed this modification to the apt-listbugs public git repository: see http://anonscm.debian.org/gitweb/?p=apt-listbugs/apt-listbugs.git;a=commitdiff;h=c7561047b211039c5d12e0006fd3af7a16d98ea6 You may therefore consider this modification as pending (that is to say, it will be present in the next upload). As far as the rest of message http://bugs.debian.org/645412#32 is concerned, I still have to read it fully and think about your proposal. I hope I manage to find the time soon... ;-) -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpymgyzLYFAH.pgp Description: PGP signature
Bug#645412: cupt: Pin from apt-listbugs does not prevent package install/upgrade
On 2011-10-17 00:40, Francesco Poli wrote: I still have to carefully read the rest of the your reply, but, first, I have to ask a question about this workaround: I am considering using a Pin-Priority of -3 (which has the advantage of being representable as a 16-bit signed integer, just in case some tool is going to read it using such a small data type...). Do you think it can be sufficiently low? Yes, it's sufficiently low for most cases, which I think is enough for a workaround. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645412: cupt: Pin from apt-listbugs does not prevent package install/upgrade
On Mon, 17 Oct 2011 14:53:40 +0300 Eugene V. Lyubimkin wrote: On 2011-10-17 00:40, Francesco Poli wrote: I still have to carefully read the rest of the your reply, but, first, I have to ask a question about this workaround: I am considering using a Pin-Priority of -3 (which has the advantage of being representable as a 16-bit signed integer, just in case some tool is going to read it using such a small data type...). Do you think it can be sufficiently low? Yes, it's sufficiently low for most cases, which I think is enough for a workaround. I am testing this modification. It does not seem to cause any problems to apt-get or to aptitude, but please note that cupt still behaves differently. # cat /etc/apt/preferences Explanation: Pinned by apt-listbugs at Mon Oct 17 20:51:13 + 2011 Explanation: #615671: derivations: ftbfs with gcc-4.5 Package: derivations Pin: version * Pin-Priority: -3 This prevents the installation of the derivations package, when using apt-get or aptitude: # aptitude install derivations No candidate version found for derivations No candidate version found for derivations No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B of archives. After unpacking 0 B will be used. # apt-get install derivations Reading package lists... Done Building dependency tree Reading state information... Done Package derivations is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'derivations' has no installation candidate However, cupt happily goes on and attempts to install derivations, until apt-listbugs kicks in and warns the user (again!) that there's a bug: # cupt install derivations Building the package cache... Initializing package resolver and worker... Scheduling requested actions... Resolving possible unmet dependencies... The following 1 packages will be INSTALLED: derivations The following 5 packages will be REMOVED: libcloog-ppl0(a) libgmpxx4ldbl(a) libppl-c4(a) libppl9(a) libpwl5(a) Need to get 0B/3953KiB of archives. After unpacking 1205KiB will be freed. Do you want to continue? [y/N/q/a/?] y Performing requested actions: Retrieving bug reports... Done Parsing Found/Fixed information... Done serious bugs of derivations (- 0.52.20100310-1) unfixed #615671 - derivations: ftbfs with gcc-4.5 Summary: derivations(1 bug) Are you sure you want to install/upgrade the above packages? [Y/n/?/...] If I recall correctly one conversation I had with you (Eugene) back on January 2010, this behavior is intentional. Only automatic installations of the low Pin-Priority package (as recommendations, or dependencies with alternatives, for instance) are prevented by cupt. The explicit request to install the low Pin-Priority package will be honored, no matter how low the Pin-Priority is. Assuming that this is true and confirmed, is the modification of apt-listbugs (so that it uses -3 instead of -40 as Pin-Priority to prevent the installation of a package) still useful? -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpGVWGEwPd1y.pgp Description: PGP signature
Bug#645412: cupt: Pin from apt-listbugs does not prevent package install/upgrade
On Mon, Oct 17, 2011 at 11:36:02PM +0200, Francesco Poli wrote: On Mon, 17 Oct 2011 14:53:40 +0300 Eugene V. Lyubimkin wrote: On 2011-10-17 00:40, Francesco Poli wrote: I still have to carefully read the rest of the your reply, but, first, I have to ask a question about this workaround: I am considering using a Pin-Priority of -3 (which has the advantage of being representable as a 16-bit signed integer, just in case some tool is going to read it using such a small data type...). Do you think it can be sufficiently low? Yes, it's sufficiently low for most cases, which I think is enough for a workaround. I am testing this modification. It does not seem to cause any problems to apt-get or to aptitude, but please note that cupt still behaves differently. # cat /etc/apt/preferences Explanation: Pinned by apt-listbugs at Mon Oct 17 20:51:13 + 2011 Explanation: #615671: derivations: ftbfs with gcc-4.5 Package: derivations Pin: version * Pin-Priority: -3 [snip] However, cupt happily goes on and attempts to install derivations, until apt-listbugs kicks in and warns the user (again!) that there's a bug: # cupt install derivations Building the package cache... Initializing package resolver and worker... Scheduling requested actions... Resolving possible unmet dependencies... The following 1 packages will be INSTALLED: derivations The following 5 packages will be REMOVED: libcloog-ppl0(a) libgmpxx4ldbl(a) libppl-c4(a) libppl9(a) libpwl5(a) Need to get 0B/3953KiB of archives. After unpacking 1205KiB will be freed. Do you want to continue? [y/N/q/a/?] y Performing requested actions: Retrieving bug reports... Done Parsing Found/Fixed information... Done serious bugs of derivations (- 0.52.20100310-1) unfixed #615671 - derivations: ftbfs with gcc-4.5 Summary: derivations(1 bug) Are you sure you want to install/upgrade the above packages? [Y/n/?/...] If I recall correctly one conversation I had with you (Eugene) back on January 2010, this behavior is intentional. I would agree with this behavior as well, since it parallels the auto vs. manual install decision. It could be argued that it's better achieved by manually removing the pin, though. Only automatic installations of the low Pin-Priority package (as recommendations, or dependencies with alternatives, for instance) are prevented by cupt. The explicit request to install the low Pin-Priority package will be honored, no matter how low the Pin-Priority is. Assuming that this is true and confirmed, is the modification of apt-listbugs (so that it uses -3 instead of -40 as Pin-Priority to prevent the installation of a package) still useful? Yes. The situation that caused me to open this bug is that every time I run “cupt safe-upgrade” I see the libclutter bug, abort the upgrade, and have to manually exclude libclutter-1.0-0 from being upgraded since the pin isn't being honored. Using such a low priority pin means I don't have to remember to add “libclutter-1.0-0-” on to the end of my command to prevent the upgrade. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org signature.asc Description: Digital signature
Bug#645412: cupt: Pin from apt-listbugs does not prevent package install/upgrade
On 2011-10-15 17:27, James Vega wrote: Well, I currently don't have any libclutter-1.0-0 versions installed, which is why the pin is for any version. Also, I tried changing the Pin-Priority to -2000 and that didn't change the outcome any. Even -2000 is too big for this case (using the current system). Something like -2 would probably work for most cases. But, obviously, editing pin priorities by hand after tools is not a solution at all. Hmm, I would find that unfortunate in this instance since apt-listbugs is a very useful tool. Indeed it is. Once/if the Cupt-specific system is rolled out, I hope it's possible to generate a snippet for Cupt as well. Hi Francesco, would it be possible for apt-listbugs also place a snippet like, say, -8- Comment: explanation of reason [ more comment lines ] Package: package name Version: 1.2-1 1.3-4 (optional line, if concerns only specific versions) Priority: -number -8- to, say a file /etc/cupt/version-priorities.d/apt-listbugs, given that a proper wishlist bug with technical details is filed a couple of months later? -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645412: cupt: Pin from apt-listbugs does not prevent package install/upgrade
On Sun, 16 Oct 2011 10:46:33 +0300 Eugene V. Lyubimkin wrote: On 2011-10-15 17:27, James Vega wrote: Well, I currently don't have any libclutter-1.0-0 versions installed, which is why the pin is for any version. Also, I tried changing the Pin-Priority to -2000 and that didn't change the outcome any. Even -2000 is too big for this case (using the current system). Something like -2 would probably work for most cases. But, obviously, editing pin priorities by hand after tools is not a solution at all. Hi Eugene! :-) I can change the default Pin-Priority that apt-listbugs uses to prevent the installation of any version of a package from -40 to -2 , if this can work for most cases with Cupt... For Apt/Aptitude, any negative Pin-Priority is equivalent: the apt_preferences(5) man page says that any P 0 will prevent the version from being installed. Hmm, I would find that unfortunate in this instance since apt-listbugs is a very useful tool. Indeed it is. Once/if the Cupt-specific system is rolled out, I hope it's possible to generate a snippet for Cupt as well. Hi Francesco, would it be possible for apt-listbugs also place a snippet like, say, -8- Comment: explanation of reason [ more comment lines ] Package: package name Version: 1.2-1 1.3-4 (optional line, if concerns only specific versions) Priority: -number -8- to, say a file /etc/cupt/version-priorities.d/apt-listbugs, given that a proper wishlist bug with technical details is filed a couple of months later? Mh... This looks like much more work than it would appear at a first glance... :-( Currently, apt-listbugs has to perform several actions with /etc/apt/preferences: not only it has to generate one stanza for /etc/apt/preferences, when the user requests a package to be pinned, but also: (A) it has to check whether a given package is already pinned in /etc/apt/preferences, in order to make the interactive command-menu work correctly (B) it has to parse /etc/apt/preferences in a cron.daily job (see /etc/cron.daily/apt-listbugs and /usr/share/apt-listbugs/aptcleanup) and drop stanzas if the corresponding bugs are fixed in the unpinned candidate version (C) maybe it has to do something else that I don't remember now... I am under the impression that adding support for a distinct pinning mechanism would require adding a lot of code, if at all possible. As far as (B) is concerned, I think an entirely new additional and independent check would need to be implemented for /etc/cupt/version-priorities.d/apt-listbugs This would not make me happy! But what about (A)? What if a package is pinned for Apt, but not for Cupt? Or vice-versa? Please remember that configuration files may be edited by hand by the (super-)user, hence it may always happen that a package is pinned for one package manager, but not for the other one... In conclusion, I am not happy to hear that you are considering the idea to make Cupt use a distinct pinning mechanism, and stop sharing pinning preferences with Apt/Aptitude. I think it would be much better, if Cupt could continue using the same pinning preferences as Apt/Aptitude (that is to say the ones found in /etc/apt/preferences). I can understand that Cupt implements a different resolver, and has therefore different needs, but, IMHO, it should try hard to re-use the settings found in /etc/apt/preferences . At least, this is what I think about this issue. I hope my contribution to the discussion helps. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgphSlGoTE07x.pgp Description: PGP signature
Bug#645412: cupt: Pin from apt-listbugs does not prevent package install/upgrade
Hi, On 2011-10-16 12:35, Francesco Poli wrote: Hi Eugene! :-) I can change the default Pin-Priority that apt-listbugs uses to prevent the installation of any version of a package from -40 to -2 , if this can work for most cases with Cupt... For Apt/Aptitude, any negative Pin-Priority is equivalent: the apt_preferences(5) man page says that any P 0 will prevent the version from being installed. That would be a nice workaround to do for the short future. As for exact default value of the number, for the APT the result is explicit version exclusion from the selection process, I'd suggest place ever lesser value, like -10. Still it will work only for the absolute majority of cases in Cupt, not all. Mh... This looks like much more work than it would appear at a first glance... :-( Indeed I was too optimistic. Still, (A) it has to check whether a given package is already pinned in /etc/apt/preferences, in order to make the interactive command-menu work correctly In the concept I have in the mind all pin stanzas will not be final, so I think this check can be totally disabled in cupt mode. (B) it has to parse /etc/apt/preferences in a cron.daily job (see /etc/cron.daily/apt-listbugs and /usr/share/apt-listbugs/aptcleanup) and drop stanzas if the corresponding bugs are fixed in the unpinned candidate version Thanks, I have quickly browsed through the all (I believe) apt_preferences specific code, and... I am under the impression that adding support for a distinct pinning mechanism would require adding a lot of code, if at all possible. As far as (B) is concerned, I think an entirely new additional and independent check would need to be implemented for /etc/cupt/version-priorities.d/apt-listbugs This would not make me happy! I think that not the much would not be needed in the logic. Specifically, 0) create a variable for a package manager used (apt or cupt or something else if ever needed); 1) substitute '/etc/apt/preferences' string across all the code by a variable (which is a good to do anyway just for refactoring), which will be filled depending on package manager used; 2) debian/apt_preferences.rb: lines 55-68 are changed (i.e. covered in if/else) in cupt mode to place all available versions (not candidate one) to 'pack_with_vers'. Should be something like 7-10 new lines of code. That's because I don't plan to derive from the APT syntax where is not needed. 'Package' line will be the same and there is no problem to support 'Explanation' line. Thus aptcleanup file should require zero changes except of 1) above. But what about (A)? What if a package is pinned for Apt, but not for Cupt? Or vice-versa? Please remember that configuration files may be edited by hand by the (super-)user, hence it may always happen that a package is pinned for one package manager, but not for the other one... That's a hardest part I guess. I'd suggest not to mix different schemes and run the package manager part two times for each mode (if both are installed; if some of them is not installed, don't call the function with respective parameters). In conclusion, I am not happy to hear that you are considering the idea to make Cupt use a distinct pinning mechanism, and stop sharing pinning preferences with Apt/Aptitude. That's fully understable. No one will be the happy of the change itself, but I want a priority system which is suitable for the full-case resolver (APT's one is not). This will allow me to make resolver a bit better for some usual cases. Also I want a priority system which Cupt users can rely on. I think it would be much better, if Cupt could continue using the same pinning preferences as Apt/Aptitude (that is to say the ones found in /etc/apt/preferences). I can understand that Cupt implements a different resolver, and has therefore different needs, but, IMHO, it should try hard to re-use the settings found in /etc/apt/preferences . I tried in the start, but I know for the some time already that it cannot work how I want, and I will switch sooner or later. See also http://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3Apin;package=apt; and specifically http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554773. Back to the my proposal, indeed it requires more work that I thought, and I will understand if you won't want to implement the changes. Thanks for consideration in any case. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645412: cupt: Pin from apt-listbugs does not prevent package install/upgrade
On Sun, 16 Oct 2011 17:12:43 +0300 Eugene V. Lyubimkin wrote: [...] On 2011-10-16 12:35, Francesco Poli wrote: Hi Eugene! :-) I can change the default Pin-Priority that apt-listbugs uses to prevent the installation of any version of a package from -40 to -2 , if this can work for most cases with Cupt... For Apt/Aptitude, any negative Pin-Priority is equivalent: the apt_preferences(5) man page says that any P 0 will prevent the version from being installed. That would be a nice workaround to do for the short future. As for exact default value of the number, for the APT the result is explicit version exclusion from the selection process, I'd suggest place ever lesser value, like -10. Still it will work only for the absolute majority of cases in Cupt, not all. I still have to carefully read the rest of the your reply, but, first, I have to ask a question about this workaround: I am considering using a Pin-Priority of -3 (which has the advantage of being representable as a 16-bit signed integer, just in case some tool is going to read it using such a small data type...). Do you think it can be sufficiently low? P.S.: yes, I know, maybe it would be better, if I converted this hard-coded value into a configuration setting, but I am convinced (probably out of laziness!) that it would be an overkill... ;-) -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpud7yY0HW6T.pgp Description: PGP signature
Bug#645412: cupt: Pin from apt-listbugs does not prevent package install/upgrade
tags 645412 + confirmed upstream quit Hi James, thank you for the report, On 2011-10-15 11:21, James Vega wrote: [...] $ cat /etc/apt/preferences Explanation: Pinned by apt-listbugs at Sat Oct 15 10:59:17 -0400 2011 Explanation: #619636: empathy fails to start: failed to create drawable Explanation: #620908: libclutter-1.0-0: clutter-using programs refuse to start on an X server that uses software Mesa Package: libclutter-1.0-0 Pin: version * Pin-Priority: -40 Attached resolver debug log shows that libclutter-1.0-0 is still selected for installation. True. That happened becaeuse of the mix of several reasons. First and main of them is Cupt's resolver always consider all versions, which is considered a feature. I can add a feature to stop considering version with some priority less than X for installing, but -40 is still too big for Cupt's resolver to satisfy the 'forget this version' rule (i.e. third reason). Second is: Cupt does not support APT preferences fully, some parts of the specification is, in my opinion, misleading or ambiguous or even disagree with APT's own behavior. Third is: even some clear parts of APT preferences are not supported since they are not designed for resolver which may consider more than one version to install. Conclusion: Your use case shows to me one more time that the current half-support situation is a mess and Cupt cannot use APT pinning system reliably. This is probably a time to drop APT pinning system support altogether and roll something that Cupt users can rely on. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645412: cupt: Pin from apt-listbugs does not prevent package install/upgrade
On Sat, Oct 15, 2011 at 09:40:40PM +0300, Eugene V. Lyubimkin wrote: First and main of them is Cupt's resolver always consider all versions, which is considered a feature. I can add a feature to stop considering version with some priority less than X for installing, but -40 is still too big for Cupt's resolver to satisfy the 'forget this version' rule (i.e. third reason). Well, I currently don't have any libclutter-1.0-0 versions installed, which is why the pin is for any version. Also, I tried changing the Pin-Priority to -2000 and that didn't change the outcome any. Conclusion: Your use case shows to me one more time that the current half-support situation is a mess and Cupt cannot use APT pinning system reliably. This is probably a time to drop APT pinning system support altogether and roll something that Cupt users can rely on. Hmm, I would find that unfortunate in this instance since apt-listbugs is a very useful tool. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org signature.asc Description: Digital signature
