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

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



On Sun, Aug 24, 2014 at 03:17:14PM -0700, Russ Allbery wrote:
> As I understand it, your primary concern is around the decision-making
> process for handling changes to priority (particularly increasing
> priority).

It's not necessarily the decision-making process.  Actually I didn't
look in detail into past override decisions, only into the current
situation.

It's the lack of transparency, packages with said added dependencies
migrating into testing before the override decision has been made, and
deliberate policy violation with "excuse" (debcheck priority data).

> That, in turn, I assume is driven by concerns about the size
> and packages included in a default Debian installation and a minimal
> Debian installation.

Yes.

> So, here's what I would propose.
> 
> First, I agree with your direction on eliminating extra and allowing
> Priority: optional packages to conflict with each other.  I think the
> overhead of managing this distinction is more trouble than it's worth, and
> the original goals largely no longer apply.
> 
> Second, I think we should document the actual way that priorities are
> changed in Debian Policy somewhere, and say explicitly that ftp-master is
> canoncial for priorities, not the package maintainers.
> 
> Third, to address your concern about the process, what about consensus
> review on debian-devel for any change in priority to required or
> important (that is not a downgrade from required to important)?  Consensus
> review isn't the best process, since sometimes it can be hard to determine
> when it's concluded, but it seems to work reasonably well for Pre-Depends,
> and I think it would at least address the awareness question.  ftp-master
> as the holders of the overrides would then rely on the debian-devel
> consensus as input to their decision on whether to approve the override
> change.
> 
> Does that sound like a workable way forward?

Sounds good to me.

But I think this bug should only deal with the first.  It's almost never
a good idea to broaden the scope of a proposed change, it makes finding
consensus more difficult.

And I don't see a reason to couple the changes, the second and third can
be done on top of the first.  Personally I don't rate the second that
important, the third is in the spirit of transparency and so I'd be
willing to second it.

Regards, Gerrit.


Reply to: