Re: Priority dependence
Frans Pop <firstname.lastname@example.org> writes:
> 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
> 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.
I would make a stronger argument than that: how much do we care about any
priorities other than important, standard, and everything else? Do we
really care about the difference between required (insofar as required
means something outside of the essential set) and important, or between
optional and extra, for *any* package?
The one remaining use case for priorities seems to be to be seed material
for installation scenarios. For that, there seem to be three basic
installation bases that people are likely to want:
* Essential-only, usually only desirable in cases like build chroots.
Doesn't use priority at all, but should just start from the essential
packages and compute a dependency closure. This seems to be what the
intention of Priority: required was, but I'm not sure I see why we
should have required separate from Essential: yes plus dependencies.
* Base installation. The smallest possible installation you can put on a
regular system and have a working and usable text-mode computer on which
you can install other things and which looks like UNIX. This seems to
be what Priority: important is supposed to give you.
* Standard installation. This should be chosen explicitly for the
installer, really. The difference between Priority: standard and
Priority: optional-or-extra would be whether we think it makes sense to
install that package in a default install.
The Policy language around this is written as if installing all of
optional were a reasonable thing to do, which hasn't been the case for
I'm probably on weaker ground in merging required and important, but I'd
like to know more background for why we have these levels and
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>