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 (https://qa.debian.org/debcheck.php?dist=sidlist=main-only-priorityarch=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.
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
Bug#759260: [summary] Bug#759260: removal of the Extra priority.
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.
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=sidlist=main-only-priorityarch=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
