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-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87tx4zd7ba....@hope.eyrie.org
