Re: Non-free RFCs in stretch
On Tue, Mar 07, 2017 at 04:40:15PM +0000, 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:
> > > 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 antimetapackage doesn't force anything on the user, its effect is only
"install this empty package to signal you're ok with this badness".
> 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.
Alas, currently Recommends are so out of whack that I tend to ignore them
rather than install around half of the time. Thus, if you need to ignore a
Recommends for an unrelated reason, your wishes wrt allowing or not
something non-free would be accidentally disobeyed.
An empty metapackage with no (non-metapackage) depends of its own has no
effect on the system other than allowing potential dependers in.
--
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄⠀⠀⠀⠀ preimage for double rot13!
Reply to: