Re: Priority dependence
Steve M. Robbins wrote:
> This is due to Debian Policy 2.5:
> Packages must not depend on packages with lower priority values
> (excluding build-time dependencies). In order to ensure this, the
> priorities of one or more packages may need to be adjusted.
> Why is this the policy? Why does it matter? Surely installing all
> the "important" packages will pull in their dependencies regardless of
> the depended-upon package's priority.
I've been wondering for some time if this policy isn't outdated and should
maybe be relaxed, at least for library packages.
I suspect the origin of the policy is that in olden days tools like
debootstrap and debian-cd relied exclusively on priority to get the
contents of the base system correct. However, for at least the last three
releases those tools have full dependency resolution support and they will
correctly pull in any dependencies regardless of priority.
The current policy results in some busy-work for FTP masters who need to
adjust priorities to comply with this policy. As there is no longer any
real necessity to have the priorities correct at all times, this is mostly
left to the final stages of release preparation (unless BRs are filed).
It also frequently results in outdated (ABI versions of) libs being
included in base installs when no package of high prio depends on a lib
anymore but the lib's prio has not yet been adjusted downwards.
Maybe we should consider changing the default prio for all library packages
to optional or lower, except for specific cases (e.g. libc) where the lib
itself can actually be considered part of the core system.
It's quite possible I'm missing reasons for the existing policy. Maybe
there are still tools or procedures that rely on matching priorities,
though I'm not aware of any and I've never heard of anything breaking
because of the prio mismatches we currently frequently have.
Something to consider for Squeeze + 1?