Bug#758234: debian-policy: allow packages to depend on packages of lower priority

[Ansgar Burchardt <ansgar@debian.org>]

Hi,

Russ Allbery writes:
> Andreas Henriksson writes:
>> Even if ftp-masters where really keen on actively managing the overrides
>> file I wonder what purpose this would serve?
>
>> As already mentioned previously in this bug backlog it would just be a
>> waste of ftp-master time.
>
>> Either way, I'm adding ftpmaster to CC now.
>
> Thanks!  Let's just ask directly.
>
> ftp-master folks, we're discussing eliminating the requirement that
> packages only depend on other packages with the same or higher priority
> (so important packages would be able to depend on optional packages), and
> deprecating the extra priority entirely (so everything at extra priority
> would end up being optional over time).  This also means eliminating the
> requirement that no two packages at optional priority conflict with each
> other.
>
> Some parts of this have more consensus than others, so I'm not sure we'll
> do all of these things.  But one question that keeps coming up is whether
> y'all care or have strong opinions about any of this.
>
> Do you care about any of these topics as ftp-master and the current
> effective owners of archive priorities?  Or would you be fine with just
> going with whatever decision the Policy discussion produces?

I do care to document current practice.  That's why I filed the bug
report ;-)

About packages depending on packages of lower priority:

There are some examples in [1] showing that a) nobody does the work to
maintain consistent priorities (see the libraries) and that b) doing so
is a bad idea anyway (see init and also the --exclude bit in [2]).

So I think there are both technical and social reasons to drop the
requirement.

  [1] https://bugs.debian.org/758234#81
  [2] https://bugs.debian.org/758234#99

About the extra priority:

First of all, most packages should be Priority: optional.  It might be
worth stating that in Policy more strongly ("Your package should usually
be at 'Priority: optional'").  The "[...] are only likely to be useful
if you already know what they are or have specialized requirements"
seems to be unclear at times (for example, most "-dev" packages or math
software or emacs extensions or "debian-policy" can be argued to only be
useful if you already know what they are[3]).

The optional/extra difference is only used for informative purposes as
far as I know: they should be handled mostly the same
(required/important/standard however have special meaning for
debootstrap).  So I understand why one might want to merge both.

I still think it has some minor uses, like showing which of several
alternative implementations might be preferred (if such a designated
alternative exists) by making that optional and the others extra.  Or
designated packages that are truly not useful for general systems (like
debug symbols).

However if no preferred implementation exists, I believe having all of
them at Priority: optional and conflict with each other is fine.

  [3] Most description of Priority levels are unclear or current
      practice differs a bit.  For example, does one expect to find
      vi(m) on any Unix-like system? ed? make?

      Does "standard" include a text-mode MUA? emacs? vim? A small TeX
      installation (optional has the full TeX distro after all)? make?
      dirmngr? gcc?

      I don't have an improved version though. Maybe state that it is
      mostly relevant to debootstrap (or "what the installer will
      install")?

Ansgar
 - speaking only for himself