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 -20000 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 -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.
>
> > 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?
Mmmmmh...
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
