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

[Cyril Brulebois]

Hi,

Ansgar Burchardt  (2017-06-21):
> I discussed this a bit on IRC with the other ftp-masters and we came
> to this summary:
> 
> 0) We would like to drop the requirement for packages to not depend on
>packages of lower priority: it is better to declare only what we
>actually want included in the installation (that is at priority >=
>standard) rather than also the dependency closure.
> 
> 1) We agree that the 'extra' priority can be dropped.

Looks good to me.

> 2) We wonder if the 'standard' priority can also be dropped: as far as
>we know, it is used only by the "standard" task and it might make
>sense to treat it the same as other tasks.
>(Depending on what works better for the installer team.)
> 
> I've Cc'ed -boot@ as this policy change affects them (I don't think
> they have to read all of the way too long bug history though).

Comparing a Section field in the archive and a Depends list, I can
imagine we would have to arch-{qualify,filter} quite a number of
packages, which might be less convenient than just relying on the
archive contents.

On the other hand, I think it would be better to be able to track the
packages getting installed over time, instead of hoping for the best
when this or that package gets a (sometimes uncoordinated) priority
bump in the archive.

Initial impression is still that such a change might be welcome at
some point, but it needs to be carefully considered on the installer
side. This might also affect downstreams.

That being said, I'm very low on bandwidth right now, with 9.0.*
fixing and/or debugging, plus 9.1 preparations.


KiBi.


signature.asc
Description: Digital signature

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

[Ansgar Burchardt]

Hi,

Russ Allbery writes:
> 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.

I discussed this a bit on IRC with the other ftp-masters and we came to
this summary:

0) We would like to drop the requirement for packages to not depend on
   packages of lower priority: it is better to declare only what we
   actually want included in the installation (that is at priority >=
   standard) rather than also the dependency closure.

1) We agree that the 'extra' priority can be dropped.

2) We wonder if the 'standard' priority can also be dropped: as far as
   we know, it is used only by the "standard" task and it might make
   sense to treat it the same as other tasks.
   (Depending on what works better for the installer team.)

I've Cc'ed -boot@ as this policy change affects them (I don't think they
have to read all of the way too long bug history though).

Ansgar

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

[Ansgar Burchardt]

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

Bug#865367: developers-reference: section 5.5.1: explicitly mention that stable and oldstable uploads must use release codename

[Henrique de Moraes Holschuh]

Package: developers-reference
Version: 3.4.18
Severity: normal

Section 5.5.1 seems to imply uploads to stable and oldstable should
target "stable" or "oldstable" in the distribution field of the
changelog entry, which is incorrect.

Please add explicit text to section 5.5.1, directing uploaders to use
the release codename, instead (e.g. "jessie", "wheezy"...).

Suggested text:

When uploading to stable, debian/changelog should use the release
codename as the target. I.e. upload to "jessie", "stretch", etc. instead
of uploading to "stable" or "oldstable".

Thank you!

-- 
  Henrique Holschuh

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

[Russ Allbery]

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?

(The underlying mental model behind these changes is the belief that
priorities have become basically meaningless to the typical user who is
installing packages -- they use other mechanisms to find the package they
want to install -- and really only serve a purpose at the priorities
higher than optional for initial installs, deciding what to put on CD
images, and for hinting purposes for tools like debootstrap.  None of the
requirements we're considering removing are particularly relevant to those
purposes, so feel like largely wasted effort by ftp-master and package
maintainers.)

-- 
Russ Allbery (r...@debian.org)   

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

[Andreas Henriksson]

Hello Bill Allombert,

On Tue, Jun 20, 2017 at 01:16:33PM +0200, Bill Allombert wrote:
> The priority in practice are set by the override file, not by packages.
> So we shoud first ask the FTP master whether they consider that the
> priorities are defined by them or by the policy, and if they are willing
> to change the override file to adjust.

I know from first-hand experience that ftp-masters generally have very
little interest in playing with priorities. In my experience they fully
rely on package maintainers asking the ftp-masters to adjust the
overrides to comply with what the package states. I've asked multiple
times for util-linux and we've come closer and closer each time
I've asked but there are still disparities (which I haven't found
the energy to care about asking yet another time) as can be seen on
https://packages.qa.debian.org/u/util-linux.html

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.

Regards,
Andreas Henriksson

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

[Bill Allombert]

On Tue, Jun 20, 2017 at 12:55:15PM +0200, Andreas Henriksson wrote:
> Hello,
> 
> The buster development cycle is open. I'm personally interested in
> working on changes that are directly related to the issue mentioned in
> the Subject. I'm sure many people will have a problem changing their
> package for the better while at the same time introducing a policy
> violation. I thus consider this issue a blocker for my work.
> (Not to mention I already maintain a package violating this part of
> policy and everyone seems to be in agreement it's the right thing to
> do. See merged bug report for history.)
> 
> Can we please get the original issues in this bug report resolved soon
> so we can actually get the risky changes done during the early
> phase of the Buster cycle?

The priority in practice are set by the override file, not by packages.
So we shoud first ask the FTP master whether they consider that the
priorities are defined by them or by the policy, and if they are willing
to change the override file to adjust.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

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

[Andreas Henriksson]

Hello,

The buster development cycle is open. I'm personally interested in
working on changes that are directly related to the issue mentioned in
the Subject. I'm sure many people will have a problem changing their
package for the better while at the same time introducing a policy
violation. I thus consider this issue a blocker for my work.
(Not to mention I already maintain a package violating this part of
policy and everyone seems to be in agreement it's the right thing to
do. See merged bug report for history.)

Can we please get the original issues in this bug report resolved soon
so we can actually get the risky changes done during the early
phase of the Buster cycle?

I don't see any pros of leaving policy in its current state related
to this issue. As I've argued elsewhere, if it's hard to come to a
conclusion about the perfect replacement I would suggest just
removing the harmful parts as an intermediate step.

Is there anything left to resolve before actually editing policy that
I might look into helping out with?

Regards,
Andreas Henriksson

Bug#822430: debian-policy: Please update 8.1.1 to use the "ldconfig" trigger instead

[Andreas Henriksson]

On Sun, Apr 24, 2016 at 01:14:49PM +0200, Niels Thykier wrote:
> Package: debian-policy
> Severity: normal
> 
> Hi,
> 
> Please update 8.1.1 to use the "ldconfig" trigger[1].
[...]

Seconded.

(I agree that the wording could possibly be improved and would like to
just second the spirit of the change and not be picky about the exact
wording.)

Regards,
Andreas Henriksson

Bug#758234: proposed wording

[Bill Allombert]

On Tue, Jun 20, 2017 at 01:37:07AM +0200, Adam Borowski wrote:
> What about this wording?:
> 
> -  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.
> +  Packages' priorities should depend solely on functionality they directly
> +  bring to the user; their priority should not be modified merely because
> +  another package makes use of them (this can be expressed via a
> +  dependency).  In particular, this means that C-like libraries almost never
> +  will have a priority above optional.
> +
> +  On the other hand, it is allowed to _move_ such elevation to a package
> +  that depends on the actual implementation: for example, if we ever declare
> +  postgresql-client to be important, it may be elevated despite being an
> +  empty package that merely depends on postgresql-client-9.6.
> 
> Obviously, this also requires changing the "extra" priority; either by
> #759260 (complete removal) or at least:
> 
> -  This contains all packages that conflict with others with
> -  required, important, standard or optional priorities, or are only
> -  likely to be useful if you already know what they are or have
> -  specialized requirements (such as packages containing only
> -  detached debugging symbols).
> +  This priority is deprecated, but may be used to denote packages
> +  that are unlikely to be useful even for most users interested
> +  in their general field.

Before anything, we should ask the ftp masyer whether they consider the
policy group or themselves responsible for setting the priority.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.