Re: Pinning vs. conflicting
Matthias Urlichs wrote:
>> >> You have not yet explained why apt pinning is not enough.
>> Simply because apt is not the only way to install packages.
>Don't synaptic and/or whatever honor these pins too?
I have no idea about synaptic, but there’s e.g. cupt (which
works as apt replacement, but probably (didn’t check) handles
its configs the same…) and dselect (which uses dpkg and thus
is one level “below” apt, and cannot be reasonably expected to
use apt’s configs).
Also, dpkg itself does have a dependency resolver, which works
only on the package relationships of course.
>> Right. Furthermore, pinning can be used by the local admin,
>> without namespacing pin priorities or somesuch, so it’s not
>> something packages should do.
>Since you don't need a package for creating a pin entry anyway, this is
Yes, but then you cannot just purge the entry easily.
>Why would you want to need a namespace for pin priorities?
>-1 is sufficient to block installation and therefore doesn't conflict
>with any other rules. What else would you need?
I was talking about pinning in general here, not pinning
for one specific case (preventing package installation).
>… esp. since their dependency resolution algorithm ends up removing the
>blocker package. As soon as there's the slightest hint of a conflict
>*anywhere* in the dependency chain. Aptitude is notorious for this.
Aptitude may be… but apt at least honours “Important: yes” on the
package, which I’ll add in my own next version and suggested Wookey
to add as well, for a subsequent upload.