I'd say this policy is not only not bringing anything good, but is actively harmful. It does cause a data loss: neither we nor the tools know what a package's real priority should be as it's overwritten by the max priority of its dependencies.
Problem 1: non-default user wishes debootstrap --exclude systemd will still install all of systemd's dependencies. Problem 2: obsolete packages libdb5.1, libboost-iostreams1.54.0, etc get installed as part of important. Problem 3: clouded analysis when pondering reducing standard (a recent debian-devel thread), a package cannot be analyzed based on its merits alone if it's a dependency. Thus, I propose not merely removing this policy requirement, but also replacing it with the opposite: # A package should not (must not?) elevate its priority just because it's # depended on unless it has extra functionality that itself warrants a given # priority. An example: * udev is depended on by P:important packages, yet creation of /dev/ nodes is something that by itself matches the definition of P:important[1] * libudev1 does nothing but serve packages that depend on in Thus, udev should have a high priority, libudev1 should not. The moment nothing depends on the latter (like due to a soname bump) it should lose its priority. With status quo, this requires human action and can't even be detected via automated means. [1]. Probably even P:required, but not essential as it's useless in vservers and in chroots. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org