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 -20000 , 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 -100000. Still it will work only for the absolute majority of cases in Cupt, not all. > Mmmmmh... > 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
