Re: Should we allow packages to depend on packages with lower priority values?
On Mon, Dec 08, 2003 at 03:17:19PM +0100, Marc Haber wrote:
> Policy 2.5 says that packages must not depend on packages with lower
> priority values. From what I tried to research, that rule is meant to
> allow CD builders to build "Debian foo standard" CDs containing
> required, important and standard packages, guaranteed that all
> dependencies are satisfied just from choosing from the Priority.
>
> This must be residue from the times when CD building tools didn't
> follow dependency chains. Today, it is trivial to build
> dependency-complete "Debian standard" CDs by including required,
> important and standard packages and following down the dependency
> chain. apt-get is a tool that can solve this, and at least the old CD
> building tools used apt-get to resolve the dependencies. This has been
> the case at least since slink when I joined the Debian user community.
>
> This being said, I'd like to point out a problem that this policy
> requirement poses.
>
> Let A and B both be packages that provide virtual package C. A is the
> default C in Debian, and is therefore Priority: important. A depends
> on E and F, which must be Priority: important as well, as required by
> current Policy.
>
> Now let's look at a system where the local administrator has decided
> to use B instead of A. Since E and F are Priority: important, dselect
> happily proceeds to install E and F on the system, even if they are
> not needed since the system in question uses B instead of A.
>
> To put it short: The last paragraph of Policy 2.5 is cruft that is no
> longer needed any more. It should be removed from Policy since we have
> had CD builder packages available that can follow dependency chains.
>
> I don't see other reasons behind the requirement, but am of course
> open to arguments. Did I overlook something?
>
I've just read Policy on this issue again, and more carefully. I think
Policy is slightly broken, in its description of 'extra'
1. Extra can include packages that conflict with packages in
'required'. How can such packages be useful, except that they correct
for the brokenness that results from removing the 'required' package?
There is something fishy here. If there is a work-around that allows
the a system to function with a 'required' package not installed, then
that package is not really required, and should not be designated as
such. If there is no work-around, then how was the 'extra' package
tested on a Debian system prior to release? Or was it just released,
because no one could ever install it, and discover/report bugs? ;-)
2. Extra can include packages that conflict with packages in
'optional'. How does one decide between two packages that conflict
with each other, and each, by itself, would be a candidate for
'optional'? Choose one for optional and the other is forced to go in
extra. Perhaps, the older more established pachage simply has pride of
place. If one simply puts both packages in extra, it is not clear that
neither has conflicts with 'required', 'important', or 'standard'
packages. It seems that two types of 'extra' are needed: 'extra type
1' is packages the conflict with 'important' and 'standard' and 'extra
type 2' is packages that conflict with a second 'extra type 2'
package.
It might be useful to build scripts that walk the full dependency/
conflicts-with database and discovers pairs of packages that conflict
with each other only in that they each depend on other packages that
conflict with each other. Lump them all into 'extra' and offer support
for discovering just what the problem is for each of them.
For example, if there became available an alternative Windowing System
that conflicted with X, that would require demoting X form 'optional'
to 'extra'.
I hope this problem can remain 'un-fixed' for a while. IMHO it is
messy.
--
Paul E Condon
pecondon@peakpeak.com
Reply to: