Re: Priority dependence
Russ Allbery writes ("Re: Priority dependence"):
> * 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.
At the time all this was invented we didn't have such sophisticated
automatic dependency calculators. Also package turnover and number of
packets were much smaller, and dependency sets of base packages were
smaller. So doing it manually was much less work.
> * 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.
Yes.
> * 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.
Yes.
The priorities do provide assistance to dependency resolution. That's
true of both automatic dependency resolvers, and humans who are
dealing with unfamiliar packages.
Perhaps the priorities should be calculated automatically by
transitive closure ? That does risk the kind of spreading priority
escalation that the libboost-* aptitude thing demonstrates.
> 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
> years.
I still think it would be useful for there to be a set of packages
which really is everything that you can sensibly install at once. If
optional isn't that any more then perhaps we could do some autoinstall
testing to make sure that it is.
Ian.
Reply to: