Re: [gentoo-dev] use.force as a complement to use.mask in profiles

[Brian Harring]

On Mon, Aug 07, 2006 at 08:31:55PM -0700, Zac Medico wrote:
> Donnie Berkholz wrote:
> > I read the portage-dev discussion, and I'm still not seeing how this is
> > superior to make.defaults.
>
> The difference with use.force is that it prevents flags, that are
> deemed extremely important, from being accidentally disabled by the
> user.

Name a few please.

I know of selinux, and multilib- all that are effectively features, 
and exist in the use conditional namespace because they
unfortunately straddle both (same issue with FEATURES=test).

So... two flags I can think of, and it requires recording the setting 
in multiple spots (features, use, and now use.force).

How is this improving it really?  It blocks people from disabling 
automatic pulling in of selinux policies, presumably trying to prevent 
them *accidentally* disabling it.

If the target is those flags... this patch doesn't really cut it 
either.
  
Said patch is actually atom -> flags forcing, not global forcing.

The original request (url to sven's discussion) was actual globally 
forced flags, not per package- would have to specify every single 
consumer of selinux flag (for example) to get the same.


> > If you want to be enabling local USE flags by
> > default, this is no less of a hack than that is -- what's truly needed
> > is some way to set per-package defaults.
>
> That's distinctly separate feature that is also needed.

What you've implemented is just that however; the only difference is 
that it's forced rather then 'default' configuration state.


> > The only valid use I can see is things like the architecture, libc, and
> > so forth. And it seems like there ought to be better solutions to this
> > than adding another hack on top of USE.
>
> The use.force feature is complementary to use.mask.  It's exactly
> the same concept, but inverted.

And both files _should_ be implemented via use deps.

I've yet to see the exit strategy for these files when use deps comes 
about also; when either portage grows it, or portage gets replaced, 
going to basically have one file that is non use dep restrictions, and 
one that allows use deps.

Why again are these two files being added?  Use use dep syntax in 
package.mask, no exit strategy needed- just requires splitting the 
deps out from there instead of reading two seperate files.

~harring