Bug#759260: [summary] Bug#759260: removal of the Extra priority.

2014-11-18 Thread Santiago Vila
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
> (https://qa.debian.org/debcheck.php?dist=sid&list=main-only-priority&arch=ANY)
> 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
drop it.

> 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".

Thanks.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#759260: [summary] Bug#759260: removal of the Extra priority.

2014-11-17 Thread Charles Plessy
Le Mon, Nov 17, 2014 at 03:55:26PM +0100, Santiago Vila a écrit :
> 
> The purpose is to allow the user to install as many optional packages
> as he/she wants without having to bother with conflicts.

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 
(https://qa.debian.org/debcheck.php?dist=sid&list=main-only-priority&arch=ANY)
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 ?

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 ? 

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#759260: [summary] Bug#759260: removal of the Extra priority.

2014-11-17 Thread Santiago Vila
On Mon, Nov 17, 2014 at 10:48:15PM +0900, Charles Plessy wrote:
> One of the potential uses of the Extra priority was to allow for
> co-installing all packages down to the Optional priority.  However,
> this goal is not seem realistic anymore given the current size of
> the Debian archive, and indeed, no concrete example (that is, not
> just a though experiment or a single exploratory attempt) of relying
> on this co-installability was given.

No. There is a little bit (or a lot) of confusion here.

It's true that the extra priority, together with the rule saying there
should not be conflicts among optional or higher packages, would allow
installing all the optional packages.

But being able to install all the optional packages is not the *goal*
itself.

The purpose is to allow the user to install as many optional packages
as he/she wants without having to bother with conflicts.

Obviously, if the set of optional or higher packages has the priority
that you can install all of them (theoretically), then it follows
naturally that every subset of such set which is closed regarding
dependencies also has such property.

As I said the day before yesterday in another thread, installing all
the optional packages (which may be technically difficult because of
the current archive size) is not actually *required* for this property
to be useful.

Therefore I object to dropping the extra priority.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#759260: [summary] Bug#759260: removal of the Extra priority.

2014-11-17 Thread Charles Plessy
Control: reopen -1
Control: tag -1 + patch

[CCed everybody who contributed in #758234 and #759260, sorry if you
were not interested in that part of the discussion]

Hello again,

Here is a summary of the discussion in #759260 (cloned from #758234), regarding
the suppression of the Extra priority.  The purpose of the original proposition
was to ease the manual adjustment of higher priorities, but aside from that
goal, there was a broad agreement that the Extra priority is not really needed
anymore.

The submitted patch (https://bugs.debian.org/759260#62) deletes the whole
paragraph on the Extra priorities, as well as the requirement for pairs of
conflicting packages that at most one is above the lowest priority.  It was
seconded in https://bugs.debian.org/759260#67, and other messages in the
discussion are also going in the same direction
(https://bugs.debian.org/759260#47).  A second call for support or objections
was given on Oct 6: (https://bugs.debian.org/759260#131), and in the absence of
feedback, the bug was closed on  Oct 20 (https://bugs.debian.org/759260#136)
was closed.  I am reopening is because I think that we have actually reached
consensus for the change.

One of the potential uses of the Extra priority was to allow for co-installing
all packages down to the Optional priority.  However, this goal is not seem
realistic anymore given the current size of the Debian archive, and indeed, no
concrete example (that is, not just a though experiment or a single exploratory
attempt) of relying on this co-installability was given.

The Extra priority was also defended on the basis that it is useful for at
least transitional packages and detached debug
symbols(https://bugs.debian.org/759260#83).  However, these are better managed
with Sections instead of Priorities.  (https://bugs.debian.org/759260#108).

The Extra priority was also said to be potentially useful to see which packages
are safe to remove, or to search for them.  If Extra were removed, it would not
be possible anymore to define defaults for conflicting Optional packages.
However I am unsure that in that case there are real defaults in the same sense
that exim is default and postifx is not.

After reading the whole thread, I think that the objections against the removal
of the Extra priority have been adequately addressed, and the people who raised
them (mostly Ansgar and Matthias), while not supporting the change, are not
opposing it to the point of asking to block it.

Therefore, I second Gerrit's proposition.  Together with Jonathan's seconding, 
this
opens the way for a Policy change if Editors agree and of course if there is no
last-minute novel argument.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org