[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: missing recommends are not RC severity



Russ Allbery:
> Holger Levsen <holger@layer-acht.org> writes:
> 
> [...]
> 
> Release folks, why this exception in the release policy?  Are you
> comfortable with Debian releasing with packages that Recommend packages
> that aren't part of the release?  (Have we historically done this?)
> 

Hi,

Thanks for the questions.  I brought it up on the last Release Team IRC
meeting[1].

To my knowledge, we have never enforced Recommends being
installable/present in testing.  As such it is safe to assume that we
have made releases where packages had recommends that could not be
satisfied (to answer your second and third question first).

The exception to the RC bug policy appears to be older than most of the
RT members in the team today.  I got two versions of the rationale,
which I will include below (as I understood them at least).
  One version appeared to be that missing recommends do not cause issues
during an "apt install" (and therefore needed not be RC)[2]. The other
was that if it is going to be RC, then the tooling should enforce it
(and it should not affect development speed considerably)[3].


As I understood it, we are open to discussing changing the policy.
However, if we are planning to make "unavailable Recommends"[4] an RC
bug then we will need to determine the scope of the problem (how many
packages get RC buggy with the given definition) and enforce the change
in britney to avoid automatic regressions in testing[5].

Thanks,
~Niels

[1]
http://meetbot.debian.net/debian-release/2018/debian-release.2018-05-23-19.01.html

[2]
http://meetbot.debian.net/debian-release/2018/debian-release.2018-05-23-19.01.log.html#l-23

[3] Given by vorlon on IRC after the meeting and therefore not present
in the log.

[4] Regardless of whether we define that as "Recommends:
<non-existing|not-in-testing>" or "<main> Recommends:
<non-free|contrib>" or "all of the above".

[5] Note that britney currently do not validate "(Build-)Depends"
between components directly.  Historically it has been less of a problem
as these problems tend to get RC bugs/blocked via other means.



Reply to: