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

Re: Non-free RFCs in stretch



On 2017-03-07 at 11:40, Ian Jackson wrote:

> Adam Borowski writes ("Re: Non-free RFCs in stretch"):
> 
>> On Tue, Mar 07, 2017 at 02:48:59PM +0000, Ian Jackson wrote:
>> 
>>> I have a suggestion for how this could be done.
>>> 
>>> We give each reason-why-a-package-might-be-nonfree-or-contrib a
>>> name in the package namespace.  I'm going to call these packages 
>>> antimetapackages.
>>> 
>>> Each package in non-free or contrib must Recommend all the 
>>> antimetapackages which apply.
>> 
>> Why Recommend rather than Depend?  The latter would allow a hard
>> conflict with everything with a specific kind of badness, which
>> seems exactly like the thing people here are looking for.
> 
> Did you see where I wrote:
> 
>   We use Recommends because these are all policy decisions which the 
>   user may wish to override on an individual basis.
> 
> The point being that it is for Debian to advise and inform users,
> but ultimately the user should have the freedom to make their own 
> compromises.  So we should assist the user to implement their
> personal policy.  But we mustn't _insist_ on the user following their
> own policy as expressed, probably inaccurately, in our dependency
> system.
> 
> In practical terms, apt makes it very hard to maintain a system
> where a Depends is violated.  Conversely it provides a good sticky
> door (in the default configuration, at least) to avoid unintentional
> violation of Recommends, but once a Recommends is violated it doesn't
> cause further problems.

Can you provide an example of how, under your proposal, someone who
wants to - e.g. - forbid the installation of any nonfree-gfdl-invariant
packages would do so? I don't see any way to accomplish that based on
Recommends:, precisely because Recommends: can be overridden.

For "Depends: foo", I'd probably try to do it by pinning foo to priority
-1, or something along those lines - but such a pin would do nothing to
prevent packages which only Recommend foo.

I could see a possible way of doing this with Conflicts: or similar,
such that you just install the packages which the ones you want to
prohibit will conflict with - but trying to set up a suitable collection
of antimetapackages to be conflicted against seems like a recipe for
madness.

I hope I'm just missing something, because this looks like a very
interesting idea. With Recommends:, however, it looks like it would do
nothing more than potentially warn the user at install time that a
package which is about to be installed violates this particular freedom
condition - and that doesn't seem like enough of a benefit to be worth
the investment.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: