Bug#758234: Bug#759260: [PATCH] Remove priority extra, make all corresponding packages priority optional
[ CC'ed #758234 as Stuart's questions are also related to that. ] Stuart Prescott stu...@debian.org writes: Gerrit Pape p...@dbnbgs.smarden.org writes: Since discussion on this topic seems to have stopped, I suggest this patch to remove the priority extra for Debian packages. All packages that currently are of priority extra shall be changed to priority optional for the reasons outlined in message #35 to this very report I find Priority: extra useful for at least transitional packages, detached debug symbols, and packages conflicting with packages of priority = important (or maybe = standard) that will continue to do so, say for example alternative init systems. Currently I therefore object this change, but don't mind limiting what the 'extra' priority should be used for further. For the purposes of this discussion, it would be very useful if you could clarify if the above objection is with your ftp-master hat on or your Debian user hat on. (This is not to say that your opinion as a Debian user is not important, but I think the context of your remark is quite important -- an ftp-master saying we need priorities is different to a user saying I like priorities.) To me, your comment sounds like one being made as a user, as it is not commenting on the role of the priorities in the organisation of the archive and, because priorities are somehow important in the organisation of the archive, that is why they are controlled by ftp-master and not by the maintainers. It would be very helpful to have an ftp-master's view as to why the Priority field is important for that at all. That's my view as a user. It's mostly useful to see which packages are safe to remove, or to search for them. One might achieve the same results with searching for multiple sections instead. Technically, I don't think we need Priority: extra. As far as I know, the main (only?) users of priorities are d-i and debootstrap which only care about required, important, standard, and ignore the optional/extra packages. Related to that: Given d-i/debootstrap are the main users, I think having d-i ignore the priority of library packages already[1] is an indication that allowing packages to depend on library packages with lower priority might not be wrong. [1] https://bugs.debian.org/758234#15 In a later message, you describe some of the busywork that ftp-master control of priorities involves and say: Finally I'm not sure if it is ftpmaster's task to tell maintainers of high priority packages what other packages they may depend on. We should by default just trust them. which makes me think that you see no reason why ftp-master is controlling Priority either. With your ftp-master hat on, is there any reason not to just rip all that overrides code out of dak and instead accept the values from the maintainers? (That directly addresses the other part of this discussion, too.) I think it's useful to be able to change what d-i installs without having to upload packages unrelated to d-i itself for this. How this is implemented doesn't matter too much (besides transition issues). If someone decides we really hate priorities, I think we could possibly replace them with meta-packages (required - minimal-system, important - base-system, standard - standard-system, nothing for optional and extra). Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758234: Bug#759260: [PATCH] Remove priority extra, make all corresponding packages priority optional
Ansgar Burchardt ans...@debian.org writes: Stuart Prescott stu...@debian.org writes: I find Priority: extra useful for at least transitional packages, detached debug symbols, and packages conflicting with packages of priority = important (or maybe = standard) that will continue to do so, say for example alternative init systems. For detached debug symbols and transitional packages, I think using the section makes more sense here, since that provides more precise information than the priority can provide. For example, transitional packages are a different sort of extra than debug symbols; both can be removed from the system without breaking important functionality, but the transitional packages are more likely to be something one wants to remove automatically. Could you say more about why you think conflicting packages having a separate priority from optional is useful? When would people use that priority information, and how? Technically, I don't think we need Priority: extra. As far as I know, the main (only?) users of priorities are d-i and debootstrap which only care about required, important, standard, and ignore the optional/extra packages. Yeah, that seems to have been the consensus of previous discussions. Related to that: Given d-i/debootstrap are the main users, I think having d-i ignore the priority of library packages already[1] is an indication that allowing packages to depend on library packages with lower priority might not be wrong. [1] https://bugs.debian.org/758234#15 There's two ways we can solve that problem: either say that priority is meaningless for library packages, or be better about automating the change in priority. I'd actually prefer the latter, since as a library maintainer I'd like to know when my package is being pulled into the standard or important set (and particularly if it's pulled into required). In some cases, it can change maintenance decisions. So, while I don't want anyone to have irritating busy-work to track this stuff, I'd really like to trigger some sort of notification to the maintainer of the elevated package, at least, and priority seems like a reasonable mechanism off of which to trigger. Even if we just automate the elevation of the priority in the overrides file along with that mail notification. I think it's useful to be able to change what d-i installs without having to upload packages unrelated to d-i itself for this. How this is implemented doesn't matter too much (besides transition issues). If someone decides we really hate priorities, I think we could possibly replace them with meta-packages (required - minimal-system, important - base-system, standard - standard-system, nothing for optional and extra). I like priorities better than meta-packages for this purpose, and I think the standard/important/required distinction really is useful, even outside of d-i. I've used it as a user when figuring out which parallel implementation of something to install. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758234: Bug#759260: [PATCH] Remove priority extra, make all corresponding packages priority optional
Hi, Russ Allbery: Could you say more about why you think conflicting packages having a separate priority from optional is useful? When would people use that priority information, and how? Let's assume that I have a large multiuser Debian system. I don't want to be bothered by people requesting this or that package all the time, so I simply install everything that's of priority extra. Or, alternately, I allow apt-get install --assume-yes of these packages by $COMMON_USER, as Policy states that there shall be no conflicts. That breaks when non-extra packages can conflict with each other. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758234: Bug#759260: [PATCH] Remove priority extra, make all corresponding packages priority optional
Russ Allbery r...@debian.org writes: Ansgar Burchardt ans...@debian.org writes: Stuart Prescott stu...@debian.org writes: Related to that: Given d-i/debootstrap are the main users, I think having d-i ignore the priority of library packages already[1] is an indication that allowing packages to depend on library packages with lower priority might not be wrong. [1] https://bugs.debian.org/758234#15 There's two ways we can solve that problem: either say that priority is meaningless for library packages, or be better about automating the change in priority. I'd actually prefer the latter, since as a library maintainer I'd like to know when my package is being pulled into the standard or important set (and particularly if it's pulled into required). It's not only libraries: package A/important could depend on utility-B. If I don't want A and use debootstrap's --exclude A, I don't need utility-B either, but will still get it if its priority is raised to important. In some cases, it can change maintenance decisions. Does this differ much from packages being picked up by other commonly installed software? Say GNOME starting to depend on my small library which suddenly raises from ~100 to 5+ reported installations? So, while I don't want anyone to have irritating busy-work to track this stuff, I'd really like to trigger some sort of notification to the maintainer of the elevated package, at least, and priority seems like a reasonable mechanism off of which to trigger. Even if we just automate the elevation of the priority in the overrides file along with that mail notification. I admit I'm not a great fan of generating more notifications. As a maintainer I already filter out most automatically generated mails I get... And dak is probably not the right place to manage subscriptions to certain notifications. Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759260: Bug#758234: Bug#759260: [PATCH] Remove priority extra, make all corresponding packages priority optional
Russ Allbery r...@debian.org writes: Ansgar Burchardt ans...@debian.org writes: Stuart Prescott stu...@debian.org writes: I find Priority: extra useful for at least transitional packages, detached debug symbols, and packages conflicting with packages of priority = important (or maybe = standard) that will continue to do so, say for example alternative init systems. For detached debug symbols and transitional packages, I think using the section makes more sense here, since that provides more precise information than the priority can provide. For example, transitional packages are a different sort of extra than debug symbols; both can be removed from the system without breaking important functionality, but the transitional packages are more likely to be something one wants to remove automatically. Hmm, yes. Having two fields where one field (Section: debug) implies the value of the other (Priority: extra) is probably a sign that the less expressive one is redundant. Could you say more about why you think conflicting packages having a separate priority from optional is useful? When would people use that priority information, and how? I think your later sentence describes my use case quite well: I like priorities better than meta-packages for this purpose, and I think the standard/important/required distinction really is useful, even outside of d-i. I've used it as a user when figuring out which parallel implementation of something to install. Of course this will not apply to all conflicting optional packages, but in some cases there will be a preferred choice. In this case alternatives could have a lower priority (i.e. extra). Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758234: Bug#759260: [PATCH] Remove priority extra, make all corresponding packages priority optional
Matthias Urlichs matth...@urlichs.de writes: Russ Allbery: Could you say more about why you think conflicting packages having a separate priority from optional is useful? When would people use that priority information, and how? Let's assume that I have a large multiuser Debian system. I don't want to be bothered by people requesting this or that package all the time, so I simply install everything that's of priority extra. Has anyone actually done this in the last five years? I'm extremely dubious this is a useful thing to do. Or, alternately, I allow apt-get install --assume-yes of these packages by $COMMON_USER, as Policy states that there shall be no conflicts. Do you actually do this? Is optional actually conflict-free? I'm pretty sure it isn't. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758234: Bug#759260: [PATCH] Remove priority extra, make all corresponding packages priority optional
Hi, Russ Allbery: Let's assume that I have a large multiuser Debian system. I don't want to be bothered by people requesting this or that package all the time, so I simply install everything that's of priority extra. Has anyone actually done this in the last five years? I'm extremely dubious this is a useful thing to do. I actually did this at one time, for a subset of sections. Until it broke too often. (At the time, filing bugs about that would likely have started yet another fight against windmills. So I didn't.) Or, alternately, I allow apt-get install --assume-yes of these packages by $COMMON_USER, as Policy states that there shall be no conflicts. Do you actually do this? Is optional actually conflict-free? I'm pretty sure it isn't. No, it's not. But I'd like it to be. However, if a consensus should emerge that it's too much hassle to file bugs against 100 packages (and then have at least half of their maintainers show up in -devel for the first time in $FOREVER, and try to argue that $OTHER_PACKAGE should be in Extra instead, because of $AD_HOC_REASON) then I'd grudgingly be OK with abolishing Optional. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758234: Bug#759260: [PATCH] Remove priority extra, make all corresponding packages priority optional
Le Wed, Aug 27, 2014 at 12:43:16AM +0200, Matthias Urlichs a écrit : Russ Allbery: Do you actually do this? Is optional actually conflict-free? I'm pretty sure it isn't. No, it's not. But I'd like it to be. However, if a consensus should emerge that it's too much hassle to file bugs against 100 packages (and then have at least half of their maintainers show up in -devel for the first time in $FOREVER, and try to argue that $OTHER_PACKAGE should be in Extra instead, because of $AD_HOC_REASON) then I'd grudgingly be OK with abolishing Optional. Hi Matthias, changes to the Policy are not made in order to trigger others to work in one direction or the other, that is, the Policy is not an instrument to change the current practice. Rather the contrary: the Policy documents the current practice. Unless you or others are going to invest significant amounts of time to make the ‘extra’ priority taken seriously by the majority of the package maintainers, you opposition has only the effect of keeping our documentation in a state of confusion that does not reflect what is actually done. So, thank you for being “grudgingly OK” with the proposed changes :) When we do not contribute to an area of Debian's development, I think that we need to be parcimonious in opposition, and keep it only for changes that have a major impact on us. 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
