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.
If the implementation in apt has too few configuration knobs to do the
right thing for all users (for example, users who want to run with
Recommends disabled by default), then I'm sure the apt authors would
accept patches.
In principle the same applies to Depends, but in the default
configuration the meaning of Recommends is closer to the desired
effect.
> Thus, if I want for example to be free of AGPL (which for some reason is
> allowed in main despite being neither Four Freedoms nor DFSG free), I ban
> nonfree-agpl and there's no way it can sneak back in.
I am uncomfortable with insisting that packages in main declare any
kind of negative thing like this. Certainly if we have
antimetapackages referred to by packages in main, they shouldn't have
names like `nonfree-*'. That would imply that Debian thinks the thing
is nonfree.
I would like to shelve this suggestion. The concept of
antimetapackages can certainly be used this way from a technical point
of view, but I think the goal there is controversial. Maintainers of
packages currently in main would probably resist the introduction of
antimetapackage tags.
Whereas the goal of enabling finer control over nonfree is, I think,
fairly uncontroversial.
So do you think we should proceed with that ? After the use of
antimetapackges is established for contrib and non-free, and we have
gained some experience, you will of course be free to re-propose this.
Regards,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
