Bug#759260: [summary] Bug#759260: removal of the Extra priority.
On Tue, 18 Nov 2014, Charles Plessy wrote:
> Le Mon, Nov 17, 2014 at 03:55:26PM +0100, Santiago Vila a écrit :
> Hi Santiago,
> practically speaking, how do you or others use the Optional priority
> to check that a package is not directly or transitively conflicting
> with another package ? First, according to debcheck
> there are thousands of packages whose Priority setting violates the
> current policy.
> Second, tools such as "apt-get --simulate" are very efficient at
> checking if the installation of one package will need or trigger the
> removal of another one. In which case would it be more efficient to
> check the priority instead, especially given the first point above ?
We can't obviously rely on the current rule if it's violated, but
violations of the rule are just a sign that we didn't try hard enough
to comply with it, not a sign that the rule is useless and we should
> Can you give concrete examples where the Extra priority has been instrumental
> for you as a user or a developer, in a way that has no practical alternative ?
> Or said differently, what would break concretely for you if tomorrow the
> Optional and Extra priorities were merged ?
As it has been pointed out by others, whenever we have a set of
mutually conflicting packages performing the same task, the package
having optional priority is the one that we recommend among them.
It is a way to tell the user "in doubt, use this one".
For example, there was a time in which there were several NFS servers
available. The only one who survived, nfs-kernel-server, is the only
one that was optional, so I installed that one when I needed a NFS
server a long time ago.
If we had not the extra priority, I would have to look at
popularity-contest or similar data. I think that it is a good thing
that we have a way to recommend packages which is independent from
"what everyone else is using".