On 23/10/14 02:04, Adam Borowski wrote:
> 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.
I agree with your analysis, although perhaps not the wording. Maybe
something like:
# The priority of a package should be based on the functionality
# of the package itself, and not on whether high-priority packages
# depend on it. In particular, shared libraries should normally
# have a low priority, even if required or essential packages
# happen to depend on them. [footnote: This ensures that a
# high-priority package transitioning to a new library dependency
# does not result in both the old and new libraries being installed
# on new systems, due to the old library's priority remaining high.]
> 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
These make excellent examples.
The cluster of packages around init, systemd and dbus is another
interesting one. systemd is non-Essential, but is *transitively*
Essential as one of several alternative dependencies for init. That
makes the current policy somewhat unclear: does init's priority
propagate to systemd-sysv, sysvinit-core, upstart, or none of them? At
the moment, init is required, the first dependency option (systemd-sysv)
is merely important (not actually enough for Policy compliance, but
presumably chosen because required priority would harm the ability to
switch away from systemd), and the others are extra.
Meanwhile, if I'd bumped up the priority of libdbus-1-3 because systemd
used to depend on it, newly debootstrap'd chroots (including those that
have sysvinit-core!) would probably still be getting libdbus-1-3 even
though systemd no longer needs it.
S
--
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/5448f677.4010...@debian.org
