Re: [gentoo-dev] Guidelines for IUSE defaults

[Daniel Campbell]

On 02/09/2017 12:59 PM, Michael Orlitzky wrote:
> On 02/09/2017 03:41 PM, Daniel Campbell wrote:
>> That's a great question. Based on a cursory look at make.conf's manpage,
>> USE_ORDER without 'pkginternal' will ignore IUSE defaults as intended.
>>
> 
> This has already been suggested like five times =P
> 
> So long as people insist on using IUSE defaults for flags that are
> critical to the package and to satisfy REQUIRED_USE (sprinkled liberally
> throughout the tree), this won't work. You'll turn off the defaults that
> are critical, too, and throw a wrench into dependency resolution.
> 
> 

(Just noticed that after I finished reading the thread; d'oh)

Hm, good point. A good number of us are against REQUIRED_USE (I don't
feel strongly either way), and I'm really not sure why we have packages
that won't work at all without specific USE flags. Now that I've read
the entire thread I see someone mentioned different arches may need
different USE flags, but that seems like something that belongs in the
profile, *if* it's a profile problem.

I'd be happy if REQUIRED_USE conflicts were handled in one of two ways:

1. emerge throws it up in your face and suggests a change (defaulting to
whichever IUSE has a +), which can then be handled with etc-update

or

2. emerge prompts you to choose a flag from the ones listed in
REQUIRED_USE, obeys it, then does #1 so you can etc-update after merging.

The downside to this is it's yet another function to add to emerge. I'm
not sure how else we can make use of REQUIRED_USE while simultaneously
allowing people the choice to not care. Could an eclass do this reliably?
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/09/2017 03:41 PM, Daniel Campbell wrote:
> That's a great question. Based on a cursory look at make.conf's manpage,
> USE_ORDER without 'pkginternal' will ignore IUSE defaults as intended.
> 

This has already been suggested like five times =P

So long as people insist on using IUSE defaults for flags that are
critical to the package and to satisfy REQUIRED_USE (sprinkled liberally
throughout the tree), this won't work. You'll turn off the defaults that
are critical, too, and throw a wrench into dependency resolution.

Re: [gentoo-dev] Guidelines for IUSE defaults

[Daniel Campbell]

On 02/09/2017 12:25 PM, Ben Kohler wrote:
> 
> 
> On Thu, Feb 9, 2017 at 2:18 PM, Daniel Campbell  > wrote:
> 
> I support the idea of a profile-set variable that determines whether or
> not IUSE is respected. Minimalists get their systems faster, we get
> something that adds to Gentoo's versatility and an additional profile.
> Of course, we should be asking the anti-IUSE people if that would be
> good enough to make the profiles/systems they want possible.
> 
> --
> Daniel Campbell - Gentoo Developer
> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net 
> fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
> 
> Can't this already be accomplished by modifying the USE_ORDER variable?
> 
> -Ben
That's a great question. Based on a cursory look at make.conf's manpage,
USE_ORDER without 'pkginternal' will ignore IUSE defaults as intended.

So if we change that from what I assume to be the default (found in the
manpage), a minimalist profile (or system) should be using:

USE_ORDER = "env:pkg:conf:defaults:repo:env.d"

If that gets combined with a profile meant explicitly for this
bare-bones use case, then I don't see why we can't make that happen. It
just requires someone who knows the use case to build the profile.

Thanks for pointing this out!

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ben Kohler]

On Thu, Feb 9, 2017 at 2:18 PM, Daniel Campbell  wrote:
>
> I support the idea of a profile-set variable that determines whether or
> not IUSE is respected. Minimalists get their systems faster, we get
> something that adds to Gentoo's versatility and an additional profile.
> Of course, we should be asking the anti-IUSE people if that would be
> good enough to make the profiles/systems they want possible.
>
> --
> Daniel Campbell - Gentoo Developer
> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
> fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
>
> Can't this already be accomplished by modifying the USE_ORDER variable?

-Ben

Re: [gentoo-dev] Guidelines for IUSE defaults

[Daniel Campbell]

On 02/03/2017 02:09 PM, William L. Thomson Jr. wrote:
> On Friday, February 3, 2017 2:53:59 PM EST Michael Orlitzky wrote:
>> On 02/03/2017 01:33 PM, Patrick McLean wrote:
>>> We might as well go back to before IUSE defaults then. Part of the
>>> advantage of IUSE defaults is maintainers don't all have to fiddle with
>>> the profiles, everything can be self-contained in the ebuild. This
>>> drastically complicates maintenance, having two locations to track and
>>> change rather than just one.
>>
>> You still retain the benefit for IUSE defaults that actually belong in
>> the base profile, just not for upstream defaults or the ones that you
>> personally prefer.
> 
> That is a side effect, as it is more about the package maintainer choosing 
> the 
> defaults. They are not messing with profiles. That base ends up with it is 
> indirect. Otherwise IUSE default flags would have to be per profile rather 
> than 
> in the package. Which would create more work for package maintainers.
> 
>>> I suspect that there is a small subset
>>> of people interested in this, and perhaps those people could maintain a
>>> "minimal" profile that unsets IUSE defaults.
>>
>> Then every IUSE default gets recorded twice: once when the maintainer
>> puts it in the ebuild, and once when I add it (negated) to the minimal
>> profile. That's a bad design even if we pretend that I can solve the
>> problem of tracking every IUSE change in the tree.
> 
> Sorry if its been suggested, I haven't followed every comment. What about 
> some 
> global env variable that could override all default IUSE. That can set in 
> base, and set what ever minimal IUSE flags that are needed.
> 
I support the idea of a profile-set variable that determines whether or
not IUSE is respected. Minimalists get their systems faster, we get
something that adds to Gentoo's versatility and an additional profile.
Of course, we should be asking the anti-IUSE people if that would be
good enough to make the profiles/systems they want possible.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Sam Jorna]

On Tue, Feb 07, 2017 at 09:11:20PM -0500, Rich Freeman wrote:
> On Tue, Feb 7, 2017 at 8:24 PM, Sam Jorna  wrote:
> > On Tue, Feb 07, 2017 at 12:00:51PM -0500, Rich Freeman wrote:
> >
> >> On Tue, Feb 7, 2017 at 10:14 AM, Ian Stakenvicius  wrote:
> >
> >> > OK, can we all decide out of this thread, that if any package is
> >> > enabling critical functionality via IUSE-defaults (or rather, IUSE
> >> > defaults alone), that this be addressed through package.use.force in
> >> > profiles OR through removal of the flag?
> >>
> >> No.
> >
> > Can this be justified a little more?
> >
> > If a package is broken when a given flag is disabled, why is it not
> > acceptable to not provide the flag?
> 
> Perhaps the issue is the definition of "critical functionality."
> 
> I may have interpreted it differently than intended.
> 
> If setting a flag one way or the other results in a package that has
> no useful purpose then I certainly agree that this shouldn't be a flag
> in the first place.  When certain combinations result in
> non-functional packages these should be caught as well (via
> REQUIRED_USE), though in really complex packages with many flags this
> may sometimes be difficult to spot.
> 
> On the other hand, I believe it should be acceptable to use IUSE
> defaults to configure a package to provide an ideal experience for the
> typical user of the package, or align with upstream.  Non-upstream
> patches that aren't related to integration are pushing it, but merely
> providing an upstream-like default experience should be the goal for
> anybody who doesn't override this one way or the other.
> 
> My brevity wasn't intended to be rude.  I've just posted extensively
> enough in this thread and didn't want to just re-iterate my previous
> emails, and so so above for clarity.

Ah, this makes sense to me - IUSE defaults being a kind of soft "new to 
Gentoo" or "minimal effort for common usage" setup, REQUIRED_USE to 
prevent bad combinations, and package.use.force for known breakages with 
individual flags.

Thanks for the clarification.

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Tue, Feb 7, 2017 at 8:24 PM, Sam Jorna  wrote:
> On Tue, Feb 07, 2017 at 12:00:51PM -0500, Rich Freeman wrote:
>
>> On Tue, Feb 7, 2017 at 10:14 AM, Ian Stakenvicius  wrote:
>
>> > OK, can we all decide out of this thread, that if any package is
>> > enabling critical functionality via IUSE-defaults (or rather, IUSE
>> > defaults alone), that this be addressed through package.use.force in
>> > profiles OR through removal of the flag?
>>
>> No.
>
> Can this be justified a little more?
>
> If a package is broken when a given flag is disabled, why is it not
> acceptable to not provide the flag?

Perhaps the issue is the definition of "critical functionality."

I may have interpreted it differently than intended.

If setting a flag one way or the other results in a package that has
no useful purpose then I certainly agree that this shouldn't be a flag
in the first place.  When certain combinations result in
non-functional packages these should be caught as well (via
REQUIRED_USE), though in really complex packages with many flags this
may sometimes be difficult to spot.

On the other hand, I believe it should be acceptable to use IUSE
defaults to configure a package to provide an ideal experience for the
typical user of the package, or align with upstream.  Non-upstream
patches that aren't related to integration are pushing it, but merely
providing an upstream-like default experience should be the goal for
anybody who doesn't override this one way or the other.

My brevity wasn't intended to be rude.  I've just posted extensively
enough in this thread and didn't want to just re-iterate my previous
emails, and so so above for clarity.

-- 
Rich

Re: [gentoo-dev] Guidelines for IUSE defaults

[Sam Jorna]

On Tue, Feb 07, 2017 at 12:00:51PM -0500, Rich Freeman wrote:
> On Tue, Feb 7, 2017 at 10:14 AM, Ian Stakenvicius  wrote:
> > On 07/02/17 08:27 AM, Michael Orlitzky wrote:
> >>
> >> The thread wasn't about discouraging IUSE defaults, rather to decide
> >> when they are appropriate. You cannot omit "pkginternal" from USE_ORDER,
> >> because you will break all of the packages whose defaults are either
> >> critical to the package, or prevent a REQUIRED_USE conflict.
> >>
> >
> > OK, can we all decide out of this thread, that if any package is
> > enabling critical functionality via IUSE-defaults (or rather, IUSE
> > defaults alone), that this be addressed through package.use.force in
> > profiles OR through removal of the flag?
> 
> No.

Can this be justified a little more?

If a package is broken when a given flag is disabled, why is it not 
acceptable to not provide the flag?

If the flag is still provided for the sake of user choice, why is it 
unacceptable to force it through package.use.force allowing the majority 
of users to not need to worry, and letting advanced users break their 
egg in their quest for an omelette?

How is this different (for example, not pointing fingers) from 
dev-lang/python[threads] being forced because it's broken without it 
(therefore critical functionality)?

Disclaimer: not trying to be argumentative, just trying understand the 
arguments. :)

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ian Stakenvicius]

On 07/02/17 12:00 PM, Rich Freeman wrote:
> On Tue, Feb 7, 2017 at 10:14 AM, Ian Stakenvicius  wrote:
>> On 07/02/17 08:27 AM, Michael Orlitzky wrote:
>>>
>>> The thread wasn't about discouraging IUSE defaults, rather to decide
>>> when they are appropriate. You cannot omit "pkginternal" from USE_ORDER,
>>> because you will break all of the packages whose defaults are either
>>> critical to the package, or prevent a REQUIRED_USE conflict.
>>>
>>
>> OK, can we all decide out of this thread, that if any package is
>> enabling critical functionality via IUSE-defaults (or rather, IUSE
>> defaults alone), that this be addressed through package.use.force in
>> profiles OR through removal of the flag?
> 
> No.
> 

Do we need to define "critical functionality" first, then?


>>
>> That at least seems like a positive first step to helping address
>> Michael's concerns, and should generally help all end-users.
>>
> 
> It only helps users who want to manually enable every single feature
> they use with an otherwise-minimal configuration.

Actually the way I see it, it helps support a USE="-*" case by not
disabling something that, although enabled via IUSE-defaults, probably
shouldn't be a flag (or should only be disable'able on certain
platforms or profiles)

Example -- USE="jit" on mozilla packages (prior it to being removed
completely, that is, which started with 51.0).  That flag was
IUSE-default-enabled, but realistically it should have probably been
package.use.force'd except on platforms (ia64,etc) and profiles
(hardened) where it doesn't work or provide what is expected from
users of those profiles.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Tue, Feb 7, 2017 at 10:14 AM, Ian Stakenvicius  wrote:
> On 07/02/17 08:27 AM, Michael Orlitzky wrote:
>>
>> The thread wasn't about discouraging IUSE defaults, rather to decide
>> when they are appropriate. You cannot omit "pkginternal" from USE_ORDER,
>> because you will break all of the packages whose defaults are either
>> critical to the package, or prevent a REQUIRED_USE conflict.
>>
>
> OK, can we all decide out of this thread, that if any package is
> enabling critical functionality via IUSE-defaults (or rather, IUSE
> defaults alone), that this be addressed through package.use.force in
> profiles OR through removal of the flag?

No.

>
> That at least seems like a positive first step to helping address
> Michael's concerns, and should generally help all end-users.
>

It only helps users who want to manually enable every single feature
they use with an otherwise-minimal configuration.

If you want to create a minimal profile feel free, and if you want to
propose some way for everybody to have their cake and eat it too
without maintainers manually maintaining per-package flags in
profiles, that is fine as well.  However, I think your proposal to use
IUSE defaults only for REQUIRED_USE conflicts is a bad one.

-- 
Rich

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ulrich Mueller]

> On Tue, 7 Feb 2017, Ian Stakenvicius wrote:

> On 07/02/17 08:27 AM, Michael Orlitzky wrote:
>> 
>> The thread wasn't about discouraging IUSE defaults, rather to
>> decide when they are appropriate. You cannot omit "pkginternal"
>> from USE_ORDER, because you will break all of the packages whose
>> defaults are either critical to the package, or prevent a
>> REQUIRED_USE conflict.

"The package manager may use it as a suggestion" seems pretty clear.
PMS doesn't require that a package manager honours these defaults.
So if anything is broken after removing them from USE_ORDER, then it
was already broken before.

Conversely, I don't see why package maintainers shouldn't use IUSE
defaults to enable (or disable, though that is rarely used) those
flags that they deem the package's best default configuration.

> OK, can we all decide out of this thread, that if any package is
> enabling critical functionality via IUSE-defaults (or rather, IUSE
> defaults alone), that this be addressed through package.use.force in
> profiles OR through removal of the flag?

Right. Also REQUIRED_USE should be used sparingly, and only for
libraries whose reverse USE dependencies would otherwise break.
In all other cases, fall back to a reasonable default if flag settings
are incompatible.

Ulrich


pgpUTmETBG0Pn.pgp
Description: PGP signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ian Stakenvicius]

On 07/02/17 08:27 AM, Michael Orlitzky wrote:
> 
> The thread wasn't about discouraging IUSE defaults, rather to decide
> when they are appropriate. You cannot omit "pkginternal" from USE_ORDER,
> because you will break all of the packages whose defaults are either
> critical to the package, or prevent a REQUIRED_USE conflict.
> 

OK, can we all decide out of this thread, that if any package is
enabling critical functionality via IUSE-defaults (or rather, IUSE
defaults alone), that this be addressed through package.use.force in
profiles OR through removal of the flag?

That at least seems like a positive first step to helping address
Michael's concerns, and should generally help all end-users.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/07/2017 02:52 AM, Ulrich Mueller wrote:
> 
> I see no point in discouraging IUSE defaults, given that they are
> purely advisory for the package manager:
> 
> "[...] any use flag name in IUSE may be prefixed by at most one of a
> plus or a minus sign. If such a prefix is present, the package manager
> may use it as a suggestion as to the default value of the use flag if
> no other configuration overrides it." [1]
> 
> Portage can be made to ignore IUSE defaults by omitting "pkginternal"
> from USE_ORDER, i.e. by adding the following line to make.conf [2]:
> 
> #USE_ORDER="env:pkg:conf:defaults:pkginternal:repo:env.d"
> USE_ORDER="env:pkg:conf:defaults:repo:env.d"
> 
> One could even think about adding this to a future minimal profile.
> 

The thread wasn't about discouraging IUSE defaults, rather to decide
when they are appropriate. You cannot omit "pkginternal" from USE_ORDER,
because you will break all of the packages whose defaults are either
critical to the package, or prevent a REQUIRED_USE conflict.

If that means IUSE defaults are the wrong solution to those problems,
then it would be beneficial to have some "Guidelines for IUSE defaults"
so that developers solve the problems correctly.

Re: [gentoo-dev] Guidelines for IUSE defaults

[Michał Górny]

W dniu 07.02.2017, wto o godzinie 21∶20 +1300, użytkownik Kent Fredric
napisał:
> On Tue, 7 Feb 2017 08:52:06 +0100
> Ulrich Mueller  wrote:
> 
> > I see no point in discouraging IUSE defaults, given that they are
> > purely advisory for the package manager:
> > 
> > "[...] any use flag name in IUSE may be prefixed by at most one of a
> > plus or a minus sign. If such a prefix is present, the package manager
> > may use it as a suggestion as to the default value of the use flag if
> > no other configuration overrides it." [1]
> 
> That's useful to know, but the problem as I see it is clearly greater
> than just USE defaults and Portages application of them:
> 

The problem is that some people believe they can solve all problems
Gentoo could ever have via more discussion on the mailing lists. They
just need more discussion to invent some more problems.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Guidelines for IUSE defaults

[Kent Fredric]

On Tue, 7 Feb 2017 08:52:06 +0100
Ulrich Mueller  wrote:

> I see no point in discouraging IUSE defaults, given that they are
> purely advisory for the package manager:
> 
> "[...] any use flag name in IUSE may be prefixed by at most one of a
> plus or a minus sign. If such a prefix is present, the package manager
> may use it as a suggestion as to the default value of the use flag if
> no other configuration overrides it." [1]

That's useful to know, but the problem as I see it is clearly greater
than just USE defaults and Portages application of them:

Its the complexity that following USE flags implies, in two places:

1. REQUIRED_USE satisfaction 

2. DEPEND=" use? (  )  !use? (  )" interactions across multiple
packages.

So while it might be *useful* to know you can ignore the defaults in IUSE
it doesn't solve the real problem of portage presenting lots of conflicting
options to a user which the user may not care about having to solve.

So as I see it, this issue is more about asking how we can use IUSE defaults
in a way that simplifies end users life, instead of making it harder.


pgpbYaByJefaT.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ulrich Mueller]

> On Thu, 02 Feb 2017, Michael Orlitzky wrote:

> A bigger problem arises from #3 and #4: it's no longer simple to get
> a minimal system. When various USE flags default on at random, you
> get users doing things like USE="-*". We can tell them not to do
> that, because of the flags in #1, but in fact very few IUSE defaults
> are critical, and most of them are junk. The only way to turn off
> all the junk ones without a huge waste of time is USE="-*".

> Can we discourage IUSE defaults except for #1 and #2? I'm equally
> guilty of #3 and #4, but I now regret them. I would also like to see
> explanations in metadata.xml of why +flags are on by default.

[Late to the topic, but two devs have asked me on IRC that I should
post this, in order to have it documented as part of the thread.]

I see no point in discouraging IUSE defaults, given that they are
purely advisory for the package manager:

"[...] any use flag name in IUSE may be prefixed by at most one of a
plus or a minus sign. If such a prefix is present, the package manager
may use it as a suggestion as to the default value of the use flag if
no other configuration overrides it." [1]

Portage can be made to ignore IUSE defaults by omitting "pkginternal"
from USE_ORDER, i.e. by adding the following line to make.conf [2]:

#USE_ORDER="env:pkg:conf:defaults:pkginternal:repo:env.d"
USE_ORDER="env:pkg:conf:defaults:repo:env.d"

One could even think about adding this to a future minimal profile.

Ulrich

[1] https://projects.gentoo.org/pms/6/pms.html#x1-670007.3
[2] make.conf(5) (in particular, note the warning for USE_ORDER)


pgpTmDoHEDZoG.pgp
Description: PGP signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Kent Fredric]

On Sat, 04 Feb 2017 16:05:50 -0500
"William L. Thomson Jr."  wrote:

> Putting increased requirements on the maintainers may be demotivating, and 
> create other problems. New profile added they are not aware of. Now they have 
> to go add IUSE defaults etc. There are a fair amount of profiles.
> 
> > For instance, perhaps one specific profile might be the "I Just want a
> > kde/qt desktop of some kind, I don't care how", and thats the point of
> > that profile, to deliver that specific experience.
> > 
> > But the individual packages will still have to decide how to best
> > satisfy that profile, which in some cases might end up preferring qt4
> > instead of qt5 for instance (perhaps out of necessity)
> > 
> > Maintainers of individual packages have the most knowledge about how to
> > best deliver that specific package, but maintainers of profiles have
> > the best understanding of what people want to see.  
> 
> Yes has to be a balance. I do not believe package maintainers will always 
> share the vision of the profiles.
> 
> Said another way, if defaults were sane enough, would profiles be necessary?
> 
> Profiles are kind of an extra added benefit to the end user, and those making 
> the profiles. Mostly a benefit for the end user. There isn't much benefit to 
> the 
> package maintainer. I could not really see anything that would give them 
> reason to spend their time on something that would not benefit them.

I think a key concept here would be the thoughts that:

a. By default, all packages are simply part of the "default profile", which 
doesn't enforce
any automagical constraints.

and that 

b. These kinds of profiles should not default to being universally inclusive, 
and instead
rely on a concept of "package membership", where constraints of "automagically 
work"
is only required for included packages and their dependencies.

Packages that are not part of any profile and are not dependencies of any 
profile
are in the Wild West of packages, and this is OK.

And it is part of the profile maintainers job to add packages to that profile,
while negotiating with the maintainer of the package how to make it work.

That way, only once a package has been explicitly added to a profile does the 
maintainer
of the package have to exercise more concern about it.

And perhaps we can have rough guidelines for "Care about this profile" and
"Don't care about this profile" like we informally do with arch-profiles.

( Where the "don't care about" implies "Care if you want to, but if you don't, 
the profile
maintainer has to keep things working if you break them )

This approach means the workload of profile-integration doesn't scale 
exponentially over portage
as an X-packages * Y-profiles equation, and it only scales as fast as each 
profile necessitates it.

That doesn't mean users can't install things outside the profile if they opt 
for a certain profile.

It just means that if a user selects a profile, everything within that profiles 
inherent subgraph
will be cohesive.

But they will still have to get their adult-pants on if they want to stray from 
that subgraph.



pgpWAbkH5Znar.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[William L. Thomson Jr.]

On Sunday, February 5, 2017 7:14:45 AM EST Kent Fredric wrote:
> On Sat, 04 Feb 2017 12:44:38 -0500
> 
> "William L. Thomson Jr."  wrote:
> > The question to ask is who do you want to create more work for?
> > People maintaining packages, or people maintaining profiles.
> 
> I would probably say "yes" to both of those, because the main objective here
> is to create less work for the end user, and that burden has to be paid by
> somebody.

Definitely needs to be developers vs end users paying the time price. Just 
increasing requirements to maintaining package can increase the entrance 
barrier. It is not like people are flocking to maintain packages as is now.

I am sure most any developer would welcome another even if they just maintain 
a single package :)

> I don't think its anything that is the responsibility of either one of those
> targets in isolation.

I would agree as I am all about working together rather than apart! That said 
I am not against teams having a particular focus, and working with others on 
their agenda.

> > Essentially your saying IUSE defaults do not belong in a package, but in a
> > profile. The problem is that is a hard rule to follow. What if the default
> > benefits all, like in a base profile. Then it might make sense to add
> > directly to ebuild than profile. But that would go against any
> > rule/policy saying only add IUSE defaults to profiles. At the same time,
> > if more than one profile needs that enabled by default, it is creating
> > more work there.
> 
> That's rather the problem as I see it, people are trying to see it as an
> "either" situation when its rather both.

It is hard to satisfy both. Both do not share the same perspective or goal.

> > While the latter is cleaner, and therefore would seem preferred. It is not
> > that much effort to negate a flag in a profile. That is likely time better
> > spent. Than to have package maintainers messing with profile defaults,
> > touching more than one profile potentially, etc.
> > 
> > Its probably best to have a team, familiar with profiles managing
> > profiles.
> > Rather than every developer working with IUSE and packages. While they may
> > be bloated, or uglier. There isn't really a way around, short of
> > something that bypasses default flags, allowing others to be set instead.
> 
> As I see it, people who manage "profiles" are essentially managing a
> distinct "vision", a template of sorts of a stereotype of a specific type
> of end user, concerning themselves with espousing the same interest over a
> wide variety of packages.

Yes, and that vision may not be shared, or even cared about by the package 
maintainer. Why should the package maintainer be burned with something that 
does not apply to them?

Seems it is the profile people who care about such. Plus profiles could be 
created without the package maintainers awareness. Or changes there in and 
they would have to be kept in the loop.

> Whereas the people who manage packages are more concerned with a more
> "upstream centered" vision of things, ( where the maintainers themselves
> are a kind of upstream ).
> 
> So naturally it will require some sort of negotiation, where the people
> who define profiles write guidelines for how packages should fit into
> those profiles, and the people who write packages should work out how
> to dovetail the upstream vision of things into those specific
> guidelines.

I agree, but I think that responsibility should fall on the profile team. They 
should contact the package maintainer and work with them on their vision. Even 
that will be taking time from the maintainer on a vision they may not share.

Putting increased requirements on the maintainers may be demotivating, and 
create other problems. New profile added they are not aware of. Now they have 
to go add IUSE defaults etc. There are a fair amount of profiles.

> For instance, perhaps one specific profile might be the "I Just want a
> kde/qt desktop of some kind, I don't care how", and thats the point of
> that profile, to deliver that specific experience.
> 
> But the individual packages will still have to decide how to best
> satisfy that profile, which in some cases might end up preferring qt4
> instead of qt5 for instance (perhaps out of necessity)
> 
> Maintainers of individual packages have the most knowledge about how to
> best deliver that specific package, but maintainers of profiles have
> the best understanding of what people want to see.

Yes has to be a balance. I do not believe package maintainers will always 
share the vision of the profiles.

Said another way, if defaults were sane enough, would profiles be necessary?

Profiles are kind of an extra added benefit to the end user, and those making 
the profiles. Mostly a benefit for the end user. There isn't much benefit to 
the 
package maintainer. I could not really see anything that would give them 
reason to spend their time on something that would not benefit them.

-- 

Re: [gentoo-dev] Guidelines for IUSE defaults

[Kent Fredric]

On Sat, 04 Feb 2017 12:44:38 -0500
"William L. Thomson Jr."  wrote:

> The question to ask is who do you want to create more work for?
> People maintaining packages, or people maintaining profiles.

I would probably say "yes" to both of those, because the main objective here
is to create less work for the end user, and that burden has to be paid by 
somebody.

I don't think its anything that is the responsibility of either one of those
targets in isolation.
> 
> Essentially your saying IUSE defaults do not belong in a package, but in a 
> profile. The problem is that is a hard rule to follow. What if the default 
> benefits all, like in a base profile. Then it might make sense to add 
> directly 
> to ebuild than profile. But that would go against any rule/policy saying only 
> add IUSE defaults to profiles. At the same time, if more than one profile 
> needs 
> that enabled by default, it is creating more work there.

That's rather the problem as I see it, people are trying to see it as an 
"either"
situation when its rather both.

> 
> While the latter is cleaner, and therefore would seem preferred. It is not 
> that much effort to negate a flag in a profile. That is likely time better 
> spent. Than to have package maintainers messing with profile defaults, 
> touching 
> more than one profile potentially, etc.
> 
> Its probably best to have a team, familiar with profiles managing profiles. 
> Rather than every developer working with IUSE and packages. While they may be 
> bloated, or uglier. There isn't really a way around, short of something that 
> bypasses default flags, allowing others to be set instead.

As I see it, people who manage "profiles" are essentially managing a distinct
"vision", a template of sorts of a stereotype of a specific type of end user,
concerning themselves with espousing the same interest over a wide variety of
packages.

Whereas the people who manage packages are more concerned with a more
"upstream centered" vision of things, ( where the maintainers themselves
are a kind of upstream ).

So naturally it will require some sort of negotiation, where the people
who define profiles write guidelines for how packages should fit into
those profiles, and the people who write packages should work out how
to dovetail the upstream vision of things into those specific
guidelines.

For instance, perhaps one specific profile might be the "I Just want a
kde/qt desktop of some kind, I don't care how", and thats the point of
that profile, to deliver that specific experience.

But the individual packages will still have to decide how to best
satisfy that profile, which in some cases might end up preferring qt4
instead of qt5 for instance (perhaps out of necessity)

Maintainers of individual packages have the most knowledge about how to
best deliver that specific package, but maintainers of profiles have
the best understanding of what people want to see.


pgpAGSraEZHjF.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[William L. Thomson Jr.]

On Saturday, February 4, 2017 9:57:01 AM EST Michael Orlitzky wrote:
> On 02/03/2017 08:07 PM, Patrick McLean wrote:
> > I think the current policy of "maintainer's discretion" is probably the
> > only reasonable way to approach IUSE defaults...
> > 
> > Leaving the IUSE defaults up to the maintainer allows said maintainer
> > to select what they consider reasonable defaults.
> 
> This is the way we currently do things:
> 
>   DEFAULTS="+apples -pears +potatoes -chicken +steak +broccoli +spatula"
>   FRUIT="${DEFAULTS} +pears -potatoes -steak -broccoli -spatula"
>   MEAT="${DEFAULTS} -apples -potatoes +chicken -broccoli -spatula"
>   VEGETABLES="${DEFAULTS} -apples -steak -spatula"
>   MISC="${DEFAULTS}"
> 
> Compare with:
> 
>   DEFAULTS=""
>   FRUIT="+apples +pears"
>   MEAT="+chicken +steak"
>   VEGETABLES="+potatoes +broccoli"
>   MISC="+apples -pears +potatoes -chicken +steak +broccoli +spatula"
> 
> One of those is stupid, regardless of what you like to eat.

The latter is cleaner than the former, there is no disagreement there.

The question to ask is who do you want to create more work for?
People maintaining packages, or people maintaining profiles.

Essentially your saying IUSE defaults do not belong in a package, but in a 
profile. The problem is that is a hard rule to follow. What if the default 
benefits all, like in a base profile. Then it might make sense to add directly 
to ebuild than profile. But that would go against any rule/policy saying only 
add IUSE defaults to profiles. At the same time, if more than one profile needs 
that enabled by default, it is creating more work there.

While the latter is cleaner, and therefore would seem preferred. It is not 
that much effort to negate a flag in a profile. That is likely time better 
spent. Than to have package maintainers messing with profile defaults, touching 
more than one profile potentially, etc.

Its probably best to have a team, familiar with profiles managing profiles. 
Rather than every developer working with IUSE and packages. While they may be 
bloated, or uglier. There isn't really a way around, short of something that 
bypasses default flags, allowing others to be set instead.

-- 
William L. Thomson Jr.

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/03/2017 08:07 PM, Patrick McLean wrote:
> 
> I think the current policy of "maintainer's discretion" is probably the
> only reasonable way to approach IUSE defaults...
> 
> Leaving the IUSE defaults up to the maintainer allows said maintainer
> to select what they consider reasonable defaults.
> 

This is the way we currently do things:

  DEFAULTS="+apples -pears +potatoes -chicken +steak +broccoli +spatula"
  FRUIT="${DEFAULTS} +pears -potatoes -steak -broccoli -spatula"
  MEAT="${DEFAULTS} -apples -potatoes +chicken -broccoli -spatula"
  VEGETABLES="${DEFAULTS} -apples -steak -spatula"
  MISC="${DEFAULTS}"

Compare with:

  DEFAULTS=""
  FRUIT="+apples +pears"
  MEAT="+chicken +steak"
  VEGETABLES="+potatoes +broccoli"
  MISC="+apples -pears +potatoes -chicken +steak +broccoli +spatula"

One of those is stupid, regardless of what you like to eat.

Re: [gentoo-dev] Guidelines for IUSE defaults

[Patrick McLean]

On Fri, 3 Feb 2017 19:59:34 -0500
Ian Stakenvicius  wrote:

> On 03/02/17 02:37 PM, Michael Orlitzky wrote:
> > On 02/03/2017 10:30 AM, Ian Stakenvicius wrote:  
> >>
> >> ok you lost me.  Could you provide an explicit example of what you
> >> would want to see enabled in the profile (while everything else is
> >> disabled) that you don't get when USE="-*" is set?  
> > 
> > USE="hardened pax_kernel ..."
> >   
> 
> ok, so global flags that are never modified via IUSE defaults.  It
> still looks to me like all you need to do to get what you want is swap
> the order of 'conf' and 'defaults' in USE_ORDER? (man make.conf)
> 
> > 
> > I don't want to turn off all IUSE defaults. Since we have no policy
> > on what IUSE defaults should be used for, half of them are
> > important, and the other half are junk. I don't want to disable the
> > ones that are critical for the package to function, and I don't
> > want to disable the ones that satisfy an (otherwise unsatisfied)
> > REQUIRED_USE constraint. 
> 
> And herein lies the crux.  "Junk" is your definition, but it's not
> necessarily the maintainer's definition.  "Critical for the package to
> function" is entirely dependent on what you expect to use the package
> for.  If you want to disable everything optional then USE="-*" will do
> that, and really all you should be losing is the ability to have
> REQUIRED_USE auto-resolve based on the IUSE defaults that are set.
> However, even in that case, it seems likely that you may well want to
> use a different option to resolve a REQUIRED_USE conflict to ensure
> your minimalist install than is the default that the maintainer
> provided.
> 

I think the current policy of "maintainer's discretion" is probably the
only reasonable way to approach IUSE defaults. Attempting to dictate
some policy based on differing definitions of what is acceptable or not
is just a path to a lot of pain for very little gain. I don't think
that there are a very large proportion of people who want some sort of
"minimal" system, sacrificing basic, expected functionality (as say
"-readline" on app-shells/bash would do) in the default configuration
.
Leaving the IUSE defaults up to the maintainer allows said maintainer
to select what they consider reasonable defaults.

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ian Stakenvicius]

On 03/02/17 02:37 PM, Michael Orlitzky wrote:
> On 02/03/2017 10:30 AM, Ian Stakenvicius wrote:
>>
>> ok you lost me.  Could you provide an explicit example of what you
>> would want to see enabled in the profile (while everything else is
>> disabled) that you don't get when USE="-*" is set?
> 
> USE="hardened pax_kernel ..."
> 

ok, so global flags that are never modified via IUSE defaults.  It
still looks to me like all you need to do to get what you want is swap
the order of 'conf' and 'defaults' in USE_ORDER? (man make.conf)

> 
> I don't want to turn off all IUSE defaults. Since we have no policy on
> what IUSE defaults should be used for, half of them are important, and
> the other half are junk. I don't want to disable the ones that are
> critical for the package to function, and I don't want to disable the
> ones that satisfy an (otherwise unsatisfied) REQUIRED_USE constraint.
> 

And herein lies the crux.  "Junk" is your definition, but it's not
necessarily the maintainer's definition.  "Critical for the package to
function" is entirely dependent on what you expect to use the package
for.  If you want to disable everything optional then USE="-*" will do
that, and really all you should be losing is the ability to have
REQUIRED_USE auto-resolve based on the IUSE defaults that are set.
However, even in that case, it seems likely that you may well want to
use a different option to resolve a REQUIRED_USE conflict to ensure
your minimalist install than is the default that the maintainer provided.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Kent Fredric]

On Thu, 2 Feb 2017 18:01:54 -0600
Gordon Pettey  wrote:

> If you want to keep this kind of thing in the ebuilds, IUSE="+blah" doesn't
> allow any granularity. Another variable USE_PROFILE should be added
> analogue to DEPENDS:
> IUSE="gnome-keyring gtk-theme kwallet pulseuadio qt-theme
> annoyingUpstreamDefault"
> USE_PROFILE="
> desktop? ( pulseaudio )
> gtk? ( gtk-theme )
> gnome? ( @gtk gnome-keyring)
> kde? ( @qt kwallet )
> qt? ( qt-theme )
> upstream? ( annoyingUpstreamDefault )
> "

This is the way I'd suggest going as well. Mostly, because needless 
double-accounting
by communicating this same information to a global profile seems like creating
work without benefit.

I'd probably suggest something like this, but with a restriction that every
"foo?" on the left hand side being a defined global term.

Especially considering that USE="-*" doesn't necessarily give you "less 
dependencies",
in the case of dev-util/pkgconfig, USE="-*" aligns with the existing (default) 
mechanic
of USE="-internal-glib", and so a "minimal system" would either 

a. Prefer dev-util/pkgconf which doesn't require glib at all ( bug #606260 [1] )

b. Prefer USE="internal-glib"

Clearly given bug #606260, our current mechanism of following upstream defaults
is not ideal for minimal systems, even though its fine for 99.99% of users.

Hence, I'd prefer something akin to:

virtual/pkgconfig: 

RDEPEND="
 profile:minimal? ( 
|| ( dev-util/pkgconf dev-util/pkgconfig[internal-glib] 
dev-util/pkgconfig )
 )
 +profile:upstream? (
|| ( dev-util/pkgconfig dev-util/pkgconf )
 )
"

Granted here I'm stepping slightly outside the conversation of USE defaults, 
because
this is a related system where the concepts of defaults are present, but are 
instead
regulated by implicit controls based on what the user has already decided to 
install.

And this example suggested usage is a bit dodgy because it could be abused by 
people
using profiles instead of useflags to control behaviour.

However:

IUSE="minimal"
IUSE_PROFILES="
minimal? ( minimal )
"
RDEPEND="
 minimal? ( 
|| ( dev-util/pkgconf dev-util/pkgconfig[internal-glib] 
dev-util/pkgconfig )
 )
 !minimal? (
|| ( dev-util/pkgconfig dev-util/pkgconf )
 )
"

Would be less abusey.

Also, this approach in general means instead of needing repoman to compute the 
interaction
of  x  for all(@profiles), it only needs to compute the 
interactions
for Profile X x Profile Y for union(x.profiles y.profiles)

( Though personally I don't think repoman needs to compute anything for 
defaults,
  I just saw somebody else mention this in a different part of this thread and 
it confused
  me. However, it *could* be useful to be able to ensure cohesion within a 
single chosen
  profile name, being able to state "If you set your profile to X and don't 
change anything
  in package.use, everything that has profile X will be installable as-is" )

And this of course brings into observation my favourite negative-useflag,
for which USE="-*" will have the opposite effect to that you intend.

__ SIMPLIFIED __ 

# May contain only the possible useflags, not setting defaults 
IUSE=""

# A list of "profilename ? ( assumed defaulted on flags )"
# where "profilename" must be a defined profile ID
# "profilename" can have a "+" to indicate it is the default profile
# if none of the others listed in IUSE_PROFILES matches a user description

IUSE_PROFILES="" 


> @ is already used for sets, so "some other use_profile's set of defined
> flags" seems reasonable. It should be additive only, so no +- prefixes
> needed (or allowed). If a package is emerged without any USE_PROFILE set,
> you might einfo "This package supports was emerged with no use profile. It
> supports blah1, blah2, and blah3. Upstream recommends blah2." USE_PROFILE
> should never have any default selected by an ebuild; if a flag is required
> to build, is shouldn't be a flag. You get independent behavior per package
> rather than listing every single package that ever existed in
> profile/package.use, package behavior actually being with the package
> instead of global profiles, and you get rid of the mess of uncustomizable
> IUSE="+something" everywhere that makes people like me tend to start off
> every new Gentoo install with echo "USE=\"-*\"" >> /etc/portage/make.conf.
> Just need to come up with sane naming convention for common possibilities
> like kde, gnome, and generic desktop.

Personally, I think encouraging people to set profiles on a per-package level
fights the cause of this feature in ways that should be governed by USE flags.

The real utility of profile-governed defaults is that you should select a given
profile, and *everything* should work out of the box *without* needing to change
use flags, and repoman should compute how "my profiles defaults expanded into 
dependencies"
would introduce a need to change USE flags on dependencies, and should raise

Re: [gentoo-dev] Guidelines for IUSE defaults

[William L. Thomson Jr.]

On Friday, February 3, 2017 2:53:59 PM EST Michael Orlitzky wrote:
> On 02/03/2017 01:33 PM, Patrick McLean wrote:
> > We might as well go back to before IUSE defaults then. Part of the
> > advantage of IUSE defaults is maintainers don't all have to fiddle with
> > the profiles, everything can be self-contained in the ebuild. This
> > drastically complicates maintenance, having two locations to track and
> > change rather than just one.
> 
> You still retain the benefit for IUSE defaults that actually belong in
> the base profile, just not for upstream defaults or the ones that you
> personally prefer.

That is a side effect, as it is more about the package maintainer choosing the 
defaults. They are not messing with profiles. That base ends up with it is 
indirect. Otherwise IUSE default flags would have to be per profile rather than 
in the package. Which would create more work for package maintainers.

> > I suspect that there is a small subset
> > of people interested in this, and perhaps those people could maintain a
> > "minimal" profile that unsets IUSE defaults.
> 
> Then every IUSE default gets recorded twice: once when the maintainer
> puts it in the ebuild, and once when I add it (negated) to the minimal
> profile. That's a bad design even if we pretend that I can solve the
> problem of tracking every IUSE change in the tree.

Sorry if its been suggested, I haven't followed every comment. What about some 
global env variable that could override all default IUSE. That can set in 
base, and set what ever minimal IUSE flags that are needed.

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/03/2017 01:33 PM, Patrick McLean wrote:
> 
> We might as well go back to before IUSE defaults then. Part of the
> advantage of IUSE defaults is maintainers don't all have to fiddle with
> the profiles, everything can be self-contained in the ebuild. This
> drastically complicates maintenance, having two locations to track and
> change rather than just one.

You still retain the benefit for IUSE defaults that actually belong in
the base profile, just not for upstream defaults or the ones that you
personally prefer.


> I suspect that there is a small subset
> of people interested in this, and perhaps those people could maintain a
> "minimal" profile that unsets IUSE defaults.

Then every IUSE default gets recorded twice: once when the maintainer
puts it in the ebuild, and once when I add it (negated) to the minimal
profile. That's a bad design even if we pretend that I can solve the
problem of tracking every IUSE change in the tree.


> Also, I would just point out that the particular IUSE default that
> you objected to in your original email does not really affect this
> "minimalist" ideal that you seem to hold. The "hpn" USE flag on
> openssh does not actually pull in any extra dependencies, it just
> adds some optimizations to the network code to make it faster.
> 

Yeah, that. OpenSSH is probably the most security-critical package on
our systems. OpenSSH is maintained upstream by a talented team of
security-conscious people. The HPN patch is,

  a) a third-party patch...
  b) that has been rejected by the talented security-conscious team...
  c) and is useless for most people.

So why are we deciding for our users that they must have it?

Re: [gentoo-dev] Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/03/2017 10:30 AM, Ian Stakenvicius wrote:
> 
> ok you lost me.  Could you provide an explicit example of what you
> would want to see enabled in the profile (while everything else is
> disabled) that you don't get when USE="-*" is set?

USE="hardened pax_kernel ..."

> 
> It's sounding more and more like you just want to be able to turn off
> all IUSE defaults, and you can effectively do that by changing the USE
> order can't you?

I don't want to turn off all IUSE defaults. Since we have no policy on
what IUSE defaults should be used for, half of them are important, and
the other half are junk. I don't want to disable the ones that are
critical for the package to function, and I don't want to disable the
ones that satisfy an (otherwise unsatisfied) REQUIRED_USE constraint.

Re: [gentoo-dev] Guidelines for IUSE defaults

[james]

On 02/03/2017 12:39 PM, james wrote:


 So imagine flags are a giant 'sparse matrix' that  I need to 'mollify'
individually periodically, then run CI on that complete-set of packages,
and then test against automated attack vectors.



So, were we to want to 'enhance' flag representation from a binary
tree form to a sparse matrix, there are many more robust things
we can do. For  those not aware of sparse matrix benefits, they 
basically provide for streamlined solving of large complex problems,

buy using special (matrix tricks) mathematical techniques to reduce
the full, valid set of parameters, into very small sets of smaller 
problems. IMO, very applicable to CI and flag set testing. These sorts 
of theories are trivial to test on minimized systems (huge shout out to 
Walt, as the king of the minimizers!).



For starters, I suggest the package listing (i.e.) the future complete
listing of gentoo packages down the 'Y' (left) axis and the actual flag 
status along the (top) X axis. Left Margin and Top margin 
representations allow the (sub)matrix to be manually viewed as a typical 
2-D table, very convenient. First we can alphabetize this 2-D flag 
matrix for a baseline (base profile) reference matrix.


But, once you start thinking about it, recalling your grammar school 
matrix algebra class, you realized that grouping flags by their myriad 
of heuristical properties, you realize that the aggregate effect of a 
flag is not binary at all, but more akin to a 'fuzzy logic' function. 
For example, cluster up a group of packagers inside the sparse matrix 
that all have the same flag, but it has different meanings, slightly per 
package. Turn that flag (on) for all packages and it has a "staccato" 
effect on the system as a whole. Turn that flag off and it is 
null-effect (at least theoretically). This is how we currently discern 
flag setting meanings, but by manually bumbling around in the dark.



Now, any number of flag activation, per package of that flag may or may 
not have secondary (tertiary etc; kinda  line harmonics on a LaPlace
or Z/s transform) effects on the system as a whole. WE as a community, 
have been ad-hoc tweaking flags and noting the effects, in an 
inconsistent manner, with only anecdotal means to share the result
of those intrinsic flag settings. Alchemy 2,000 years ago was almost 
identical to how we (today) analyze flag effects. Grouping all the 
packages with a given flag, for CI studies allow for row reduction in 
the sparse matrix of flags, as CI runs are amassed into a larger 
collective of heuristical interpretations of such specific flag groupings.



Or that is my latest treaty_proposal, on how to filter a particular 
collection of flag settings and installed packages. I am open to other 
ideas too, as well as traditional regression testing in a hybrid model.



Ultimate flexibility in the profile/flag tree, greatly simplifies the
automation of CI testing and automated results interpretations, imo. So 
hopefully I have sufficiently explained my pathway forward, what I need, 
and how these seemingly disparate issues, are all really just moving 
parts of a much larger (system) need.



At the very least a 100% flexible flag settings/negation, via a profile 
tree and other mechanisms, will not hinder the formation of matrix 
representations of flag configuration sets, which are keenly needed to 
draw reasonable automated conclusions from CI, at least related to flag 
settings and secondary (inter-intra) flag setting interactions.



hth,
James

Re: [gentoo-dev] Guidelines for IUSE defaults

[Patrick McLean]

On Fri, 3 Feb 2017 08:43:50 -0500
Michael Orlitzky  wrote:

> On 02/03/2017 08:21 AM, Ian Stakenvicius wrote:
> >>
> >> How about rather changing our defaults to satisfy the minimalists
> >> who don't mind drastically reduced functionality and usability in
> >> pursuit of "minimalism" we just strive to make USE="-*" mostly
> >> usable, so the minimalists can get what they want, while still
> >> having sane defaults. 
> > 
> > I'm in favour of this too -- I know we don't "officially" support
> > USE="-*" but I think we should still strive to make it work with
> > minimal effort to end-users -- that effort being mainly setting
> > whatever is necessary for REQUIRED_USE resolution.
> >   
> 
> It will never be easy, because USE="-*" overrides your profile. What
> people want is a way to have USE="-*" apply between the base profile
> and the one that they select.
> 
> This is all easily fixed by creating a new profile one-level above
> base where developers can put their favorite USE flags:
> 
>   1. We create a new empty profile called "penultimate" inheriting
>  from base.
> 
>   2. Update the profiles that inherit from base to inherit from
>  penultimate.
> 
>   3. Move every upstream and maintainer-pet IUSE default into the
>  penultimate profile.
> 
>   4. Make it policy that IUSE defaults should only be used for
>  critical flags and REQUIRED_USE persuasion.
> 
>   5. Now we can create embedded, hardened, etc. profiles that inherit
>  from base and get a minimal working set of USE flags.
> 

We might as well go back to before IUSE defaults then. Part of the
advantage of IUSE defaults is maintainers don't all have to fiddle with
the profiles, everything can be self-contained in the ebuild. This
drastically complicates maintenance, having two locations to track and
change rather than just one.

I don't know that I would agree that making an absolutely "minimal"
build as easy as possible is something that most people want
(especially if it makes maintainership more complicated for a
significant number of packages). I suspect that there is a small subset
of people interested in this, and perhaps those people could maintain a
"minimal" profile that unsets IUSE defaults.

Also, I would just point out that the particular IUSE default that
you objected to in your original email does not really affect this
"minimalist" ideal that you seem to hold. The "hpn" USE flag on
openssh does not actually pull in any extra dependencies, it just
adds some optimizations to the network code to make it faster.

Re: [gentoo-dev] Guidelines for IUSE defaults

[james]

On 02/03/2017 01:12 AM, Walter Dnes wrote:

On Thu, Feb 02, 2017 at 01:01:52PM -0500, Rich Freeman wrote


Is there a better way we can have our cake and eat it too?  I'll admit
that a huge package.use on the minimal profile isn't a whole lot
better than a huge package.use on all the other profiles.

Do we need another form of syntax in individual ebuilds to try to
separate out the various cases you cite?  Does anybody care to
actually suggest one?

I still think that we shouldn't encourage users to lightly deviate
from all the upstream defaults.  There are of course legitimate
reasons for doing so, and you and I can probably appreciate when we
should do this, but for somebody starting out we're giving them a lot
of rope to hang themselves with.


  The "case" for IUSE often depends on a fallacious strawman argument
about USE="-*".  The strawman argument is that people run with the USE
variable in make.conf consisting of "USE=-*" and that every package
requires an entry in package.use WRONG! WRONG! WRONG!  That is a braindead
approach.  The way I recommend doing it is...

USE="-* fu bar blah blah blah"

...where commonly-used flags are included in USE.  My rule-of-thumb is

Given that
* not including a flag in USE requires X entries adding it in package.use
* including a flag in USE requires Y entries negating it in package.use

If ( X > Y ) then
   include the the flag in USE
else
   do not include the the flag in USE
end if

  I effectively "build my own profile" rather than depend on multiple
levels of inheritance.  My current desktop runs with the following USE
flags...

USE="X apng bindist ffmpeg jpeg opengl png szip truetype x264 x265 xorg threads webp 
-acl -berkdb -caps -cracklib -crypt -filecaps -gallium -gdbm -graphite -gstreamer -iconv 
-introspection -ipc -iptables -ipv6 -libav -llvm -manpager -nls -openmp -pam -pch 
-sendmail -tcpd -udev -unicode -xinerama"

  Note all the negative flags.  I'll try installing uclibc to a laptop
one of these days.  I figure that it'll probably have a shorter USE line
if I start USE with "-*", and I will not have a larger package.use file.


+1

I've used Gentoo since 2004. I started down the minimal flag path, first 
building iptables-based firewalls on gentoo. So that would be a 
(minimal)base+iptables profile. My historical experience is that flag 
negation has been a "dirty function" over the years; i.e. not consistent
sometimes, across time. That has resulted in a variety of flag negation 
strategies to "tweek" the final results, seemingly more of an art form
with hidden tricks, and a robust (documented) semantic. Most hard to 
track down problems were in the actual packages (ebuild) as we have 
danced across EAPI standards all the way back to no EAPI standards and a 
weak complement of documentation.


This happened because of 'package creep' or just needing/wanting to add 
more and more codes to the firewalls. So now, my firewalls range from 
truly minimal, all the way to enhancements that supercede suricata. So 
imagine flags are a giant 'sparse matrix' that  I need to 'mollify' 
individually periodically, then run CI on that complete-set of packages, 
and then test against automated attack vectors.



With CI, in a stage-4 install, we minimalist could test the our 
collective of (minimized flag) packages and do our own CI. Even perhaps
sharing the result of our CI testing of such minimized systems when a 
gentoo mechanism is available that can handle such massive amounts of 
data. I proposed this (CI-stage-4) a while back in a gentoo-dev thread 
and so here we are, again. Granted, this in-house gentoo-CI work was not 
ready for such wider usage, when I last looked, but it will go a long 
way in providing a robust tool for minimalist. Many are getting into the 
minimalist systems, for security reasons too.


My needs, on the surface, may(maynot) appear to diverge from Walts, but 
I surely hope that whatever the consensus solution is, at least for now, 
it is flexible enough to coalesce all of the various minimalist into the 
same area of the profile tree. We can then share ideas and results of 
testing.


I really need to apologize to many devs. But, I'm getting very close to
having something absolutely wonderful, about 90% thanks to the gentoo
devs. I do not want to appear to be childish throwing a tantrum about
this, but, well, I just really cannot help it; as y'all can imagine?


hth,
James

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ian Stakenvicius]

On 03/02/17 08:43 AM, Michael Orlitzky wrote:
> On 02/03/2017 08:21 AM, Ian Stakenvicius wrote:
>>>
>>> How about rather changing our defaults to satisfy the minimalists who
>>> don't mind drastically reduced functionality and usability in pursuit
>>> of "minimalism" we just strive to make USE="-*" mostly usable, so the
>>> minimalists can get what they want, while still having sane defaults. 
>>>
>>
>> I'm in favour of this too -- I know we don't "officially" support
>> USE="-*" but I think we should still strive to make it work with
>> minimal effort to end-users -- that effort being mainly setting
>> whatever is necessary for REQUIRED_USE resolution.
>>
> 
> It will never be easy, because USE="-*" overrides your profile. What
> people want is a way to have USE="-*" apply between the base profile and
> the one that they select.
> 

ok you lost me.  Could you provide an explicit example of what you
would want to see enabled in the profile (while everything else is
disabled) that you don't get when USE="-*" is set?

It's sounding more and more like you just want to be able to turn off
all IUSE defaults, and you can effectively do that by changing the USE
order can't you?





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/03/2017 08:21 AM, Ian Stakenvicius wrote:
>>
>> How about rather changing our defaults to satisfy the minimalists who
>> don't mind drastically reduced functionality and usability in pursuit
>> of "minimalism" we just strive to make USE="-*" mostly usable, so the
>> minimalists can get what they want, while still having sane defaults. 
>>
> 
> I'm in favour of this too -- I know we don't "officially" support
> USE="-*" but I think we should still strive to make it work with
> minimal effort to end-users -- that effort being mainly setting
> whatever is necessary for REQUIRED_USE resolution.
> 

It will never be easy, because USE="-*" overrides your profile. What
people want is a way to have USE="-*" apply between the base profile and
the one that they select.

This is all easily fixed by creating a new profile one-level above base
where developers can put their favorite USE flags:

  1. We create a new empty profile called "penultimate" inheriting
 from base.

  2. Update the profiles that inherit from base to inherit from
 penultimate.

  3. Move every upstream and maintainer-pet IUSE default into the
 penultimate profile.

  4. Make it policy that IUSE defaults should only be used for
 critical flags and REQUIRED_USE persuasion.

  5. Now we can create embedded, hardened, etc. profiles that inherit
 from base and get a minimal working set of USE flags.

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ian Stakenvicius]

On 02/02/17 10:14 PM, Patrick McLean wrote:
> On Thu, 2 Feb 2017 20:40:38 -0500
> Michael Orlitzky  wrote:
> 
>> On 02/02/2017 01:01 PM, Rich Freeman wrote:
>>> On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky 
>>> wrote:  

 If (base == minimal), then all of the upstream defaults need to be
 added to package.use for the upstream-defaults profile. That's
 bad,  
>>>
>>> I'll go further and say that it is unacceptably bad.
>>>   
>>
>> Only if anyone wants an upstream-defaults profile. But nobody's asked
>> for one, in contrast with the large number of users who want minimal.
>>
>>
>>> Is there a better way we can have our cake and eat it too?  I'll
>>> admit that a huge package.use on the minimal profile isn't a whole
>>> lot better than a huge package.use on all the other profiles.  
>>
>> Every important upstream default is already enabled in some profile.
>> If dropping a particular IUSE default breaks desktop systems, then
>> that flag belongs enabled in the desktop profile. If it breaks every
>> system, then let's keep it default.
>>
> 
> How about rather changing our defaults to satisfy the minimalists who
> don't mind drastically reduced functionality and usability in pursuit
> of "minimalism" we just strive to make USE="-*" mostly usable, so the
> minimalists can get what they want, while still having sane defaults. 
> 

I'm in favour of this too -- I know we don't "officially" support
USE="-*" but I think we should still strive to make it work with
minimal effort to end-users -- that effort being mainly setting
whatever is necessary for REQUIRED_USE resolution.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ian Stakenvicius]

On 02/02/17 08:21 PM, Michael Orlitzky wrote:
> On 02/02/2017 06:41 PM, Ian Stakenvicius wrote:
>> Responding here instead of the first time it was posted, just 'cause.
>>
>> On 02/02/17 06:35 PM, james wrote:
>>> "
>>> I'm not saying that we should have a minimal experience out-of-the-box,
>>> only that the base profile should result in an effectively-minimal set
>>> of USE flags. Adding IUSE defaults is essentially adding defaults to the
>>> base profile."
>>
>> Yes.  More specifically, it's adding these defaults without setting
>> the flags globally, thereby not introducing system-wide defaults
>> across all packages but only those that make sense on a per-package
>> basis for that package to operate properly.
>>
>> IMO this is the effectively minimal-set of use flags we should have.
> 
> I... agree? We should enable the flags that are necessary for the
> package to work, and we should enable whatever is necessary to avoid
> REQUIRED_USE roadblocks. That's what I started out by suggesting.
> 

Where we disagree is that this includes all of scenarios #2, #3, and
#4 IMO.  #4 perhaps less so than the others, but IMO if there is a
good reason feature-wise for that to be default-enabled, then the
maintainer should still default-enable it and do so via IUSE-defaults.

Remember one of the primary reasons IUSE-defaults came about is
because maintainers were doing all of these things, but using "no*"
flags so that the features would be default-enabled.  I don't think
any of us want to see that again.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Walter Dnes]

On Thu, Feb 02, 2017 at 01:01:52PM -0500, Rich Freeman wrote

> Is there a better way we can have our cake and eat it too?  I'll admit
> that a huge package.use on the minimal profile isn't a whole lot
> better than a huge package.use on all the other profiles.
> 
> Do we need another form of syntax in individual ebuilds to try to
> separate out the various cases you cite?  Does anybody care to
> actually suggest one?
> 
> I still think that we shouldn't encourage users to lightly deviate
> from all the upstream defaults.  There are of course legitimate
> reasons for doing so, and you and I can probably appreciate when we
> should do this, but for somebody starting out we're giving them a lot
> of rope to hang themselves with.

  The "case" for IUSE often depends on a fallacious strawman argument
about USE="-*".  The strawman argument is that people run with the USE
variable in make.conf consisting of "USE=-*" and that every package
requires an entry in package.use WRONG! WRONG! WRONG!  That is a braindead
approach.  The way I recommend doing it is...

USE="-* fu bar blah blah blah"

...where commonly-used flags are included in USE.  My rule-of-thumb is

Given that
* not including a flag in USE requires X entries adding it in package.use
* including a flag in USE requires Y entries negating it in package.use

If ( X > Y ) then
   include the the flag in USE
else
   do not include the the flag in USE
end if

  I effectively "build my own profile" rather than depend on multiple
levels of inheritance.  My current desktop runs with the following USE
flags...

USE="X apng bindist ffmpeg jpeg opengl png szip truetype x264 x265 xorg threads 
webp -acl -berkdb -caps -cracklib -crypt -filecaps -gallium -gdbm -graphite 
-gstreamer -iconv -introspection -ipc -iptables -ipv6 -libav -llvm -manpager 
-nls -openmp -pam -pch -sendmail -tcpd -udev -unicode -xinerama"

  Note all the negative flags.  I'll try installing uclibc to a laptop
one of these days.  I figure that it'll probably have a shorter USE line
if I start USE with "-*", and I will not have a larger package.use file.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/02/2017 10:16 PM, Patrick McLean wrote:
> 
> There are people who run servers on Gentoo, and don't particularly want
> minimalism, then want a normal Linux system level of functionality (ie
> upstream and/or sane defaults) without having to add dozens of USE
> flags to random packages throughout the system.
> 

Then somebody should go through a typical Ubuntu install and add all of
those packages to @system. That will make most people happy, and the
minimalists can just mask what they don't need.

Re: [gentoo-dev] Guidelines for IUSE defaults

[Patrick McLean]

On Thu, 2 Feb 2017 21:06:33 -0500
Michael Orlitzky  wrote:

> On 02/02/2017 09:00 PM, Sam Jorna wrote:
> >
> > Consider: a new user, coming from Ubuntu or Fedora or Windows,
> > starts building their system. They start installing packages they
> > want, only to find that half of the package isn't there because no
> > USE flags were enabled. They have to enable these flags for almost
> > every package they want because there's no defaults, you must
> > manually specify anything that's not a direct dependency or forced
> > by profile.  
> 
> Desktop profile!! We have a desktop profile!!! Why is the base
> profile a better location for new-user-with-a-desktop defaults than
> the **desktop** profile?
> 
> I'm going crazy. I give up.
> 

There are people who run servers on Gentoo, and don't particularly want
minimalism, then want a normal Linux system level of functionality (ie
upstream and/or sane defaults) without having to add dozens of USE
flags to random packages throughout the system.

Re: [gentoo-dev] Guidelines for IUSE defaults

[Patrick McLean]

On Thu, 2 Feb 2017 20:40:38 -0500
Michael Orlitzky  wrote:

> On 02/02/2017 01:01 PM, Rich Freeman wrote:
> > On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky 
> > wrote:  
> >>
> >> If (base == minimal), then all of the upstream defaults need to be
> >> added to package.use for the upstream-defaults profile. That's
> >> bad,  
> > 
> > I'll go further and say that it is unacceptably bad.
> >   
> 
> Only if anyone wants an upstream-defaults profile. But nobody's asked
> for one, in contrast with the large number of users who want minimal.
> 
> 
> > Is there a better way we can have our cake and eat it too?  I'll
> > admit that a huge package.use on the minimal profile isn't a whole
> > lot better than a huge package.use on all the other profiles.  
> 
> Every important upstream default is already enabled in some profile.
> If dropping a particular IUSE default breaks desktop systems, then
> that flag belongs enabled in the desktop profile. If it breaks every
> system, then let's keep it default.
> 

How about rather changing our defaults to satisfy the minimalists who
don't mind drastically reduced functionality and usability in pursuit
of "minimalism" we just strive to make USE="-*" mostly usable, so the
minimalists can get what they want, while still having sane defaults. 

Re: [gentoo-dev] Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/02/2017 09:31 PM, Rich Freeman wrote:
> 
> The desktop profile is going to do things like enable X11 support by
> default.  It isn't going to do things like enable bzip support in
> ffmpeg (but not the new experimental codec that causes it to crash 25%
> of the time, but which apparently works great if you use libav
> instead), or tools support in tripwire, or e2fsprogs support in
> libarchive, or threads support in beecrypt, or any of a million other
> things that aren't desktop-specific.

Then throw in an intermediate profile

  base -> all-that-junk -> desktop

and everyone that's inheriting from base now can inherit from the new
profile instead. Nothing changes, except we get the cruft out of base
and into a new profile that people can ignore. The defaults are still
recorded once, in one place. Just in a profile now instead of in IUSE.

Re: [gentoo-dev] Guidelines for IUSE defaults

[Sam Jorna]

On Thu, Feb 02, 2017 at 09:26:20PM -0500, Michael Orlitzky wrote:
> On 02/02/2017 09:22 PM, Sam Jorna wrote:
> > 
> > Also, how would this work with local USE flags as opposed to global 
> > flags? Would they be acceptable to have IUSE defaults?
> > 
> 
> Exactly the same way as global flags: drop an entry in the desktop
> profile's package.use.

I can understand the reasoning behind using this, but it seems 
unnecessarily laborious to do so - as I said, it would mean playing 
around with profiles whenever changing a package for which flags are 
defaulted.

Perhaps some standardisation of what warrants an IUSE default could 
help, otherwise you might end up with the same situation, just relocated 
into the profiles namespace instead of the package.

Having said that, I'm not strongly opposed, just trying to sound out 
pros/cons/gotcha's.

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Thu, Feb 2, 2017 at 9:06 PM, Michael Orlitzky  wrote:
> On 02/02/2017 09:00 PM, Sam Jorna wrote:
>>
>> Consider: a new user, coming from Ubuntu or Fedora or Windows, starts
>> building their system. They start installing packages they want, only to
>> find that half of the package isn't there because no USE flags were
>> enabled. They have to enable these flags for almost every package they
>> want because there's no defaults, you must manually specify anything
>> that's not a direct dependency or forced by profile.
>
> Desktop profile!! We have a desktop profile!!! Why is the base
> profile a better location for new-user-with-a-desktop defaults than the
> **desktop** profile?
>

The desktop profile is going to do things like enable X11 support by
default.  It isn't going to do things like enable bzip support in
ffmpeg (but not the new experimental codec that causes it to crash 25%
of the time, but which apparently works great if you use libav
instead), or tools support in tripwire, or e2fsprogs support in
libarchive, or threads support in beecrypt, or any of a million other
things that aren't desktop-specific.  Sure, you can do this with a
bazillion package-specific profile settings, but that is a ton of
cruft for every profile except a minimal profile.

USE settings aren't in some kind of natural heirarchy where desktop
users want them all on and embedded users want them all off.  There
are a million often-orthogonal choices, and anybody could potentially
need any of them, or not want any of them.

Take threads support.as a random example.  There are lots of packages
that default it on, and lots that default it off, and as far as I can
tell none of the profiles change it either way, other than for the odd
package where the preference is arch-specific.  This probably reflects
the feature not being equally stable in all packages, or maybe in some
cases it pulls in heavyweight dependencies where it isn't worth the
tradeoff for a typical user.  Just setting the flag on/off globally
loses all that nuance, which package maintainers have apparently taken
the time to create.  And threads support has nothing to do with
whether you want desktop vs server vs embedded for the most part,
except where it pulls in heavy dependencies, and again that requires
nuance.

I get that there are many people who run Gentoo because it lets them
strip down their systems.  I want to support that as best we can.  I
just don't think that we can just abandon the more typical use case
(IMO) of upstream defaults just to make setting that up a little
easier.  Gentoo enables all kinds of exotic configurations, but it
does so starting from a baseline that is reasonably close to something
like Arch or Debian.  That is a pretty sane place to build off of, but
Gentoo lets you get a lot further away from that faster if that is
what you want.  That is why we use openrc+bash as our starting point
and not busybox.  There are users who swear by busybox mdev and if
they're willing to write the wiki pages to make that work more power
to them, and I'm fine with having that in a virtual/etc to make life
easier on them when that makes sense.  I just think as a baseline it
makes more sense to start out close to where everybody else starts.

If this were just about a few global USE flags in the desktop profile,
that would be a different matter.

-- 
Rich

Re: [gentoo-dev] Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/02/2017 09:22 PM, Sam Jorna wrote:
> 
> Also, how would this work with local USE flags as opposed to global 
> flags? Would they be acceptable to have IUSE defaults?
> 

Exactly the same way as global flags: drop an entry in the desktop
profile's package.use.

Re: [gentoo-dev] Guidelines for IUSE defaults

[Sam Jorna]

On Thu, Feb 02, 2017 at 09:06:33PM -0500, Michael Orlitzky wrote:
> On 02/02/2017 09:00 PM, Sam Jorna wrote:
> >
> > Consider: a new user, coming from Ubuntu or Fedora or Windows, starts 
> > building their system. They start installing packages they want, only to 
> > find that half of the package isn't there because no USE flags were 
> > enabled. They have to enable these flags for almost every package they 
> > want because there's no defaults, you must manually specify anything 
> > that's not a direct dependency or forced by profile.
> 
> Desktop profile!! We have a desktop profile!!! Why is the base
> profile a better location for new-user-with-a-desktop defaults than the
> **desktop** profile?
> 
> I'm going crazy. I give up.

That would also mean two commits when adding or removing a package with 
any defaults - one for profiles/, one for the package itself - as well 
as when flags change for a given package.

Also, how would this work with local USE flags as opposed to global 
flags? Would they be acceptable to have IUSE defaults?

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Thu, Feb 2, 2017 at 8:40 PM, Michael Orlitzky  wrote:
> On 02/02/2017 01:01 PM, Rich Freeman wrote:
>> On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky  wrote:
>>>
>>> If (base == minimal), then all of the upstream defaults need to be added
>>> to package.use for the upstream-defaults profile. That's bad,
>>
>> I'll go further and say that it is unacceptably bad.
>>
>
> Only if anyone wants an upstream-defaults profile. But nobody's asked
> for one, in contrast with the large number of users who want minimal.
>

People already have one effectively, so they're not going to ask.

But, if it makes you happier, I'll ask for one.  :)

If Gentoo didn't have a reasonable way to get mostly upstream
defaults, I probably wouldn't be using Gentoo.

>
>> I still think that we shouldn't encourage users to lightly deviate
>> from all the upstream defaults.
>
> Deviating from upstream defaults is why we have USE flags in the first
> place. No one really wants the upstream defaults, they want
>
>   (nothing) + (what their profile provides) + (what they enable),

Well, I'm somebody, and I want:

(upstream defaults) + (profile settings) + (what I enable) - (what I disable)

I certainly don't set USE=-*, even on my containers.

>
> If dropping an IUSE default hurts some profile, then stick the default
> in that profile. Nothing breaks, and it's not too much work

There are probably thousands of package+USE combinations in IUSE
statements.  Putting these all into a profile is anything but
straightforward.

I don't want globally-enabled/disabled USE flags in my base profile.
I want the settings that make sense for each specific package, which
requires taking the time to evaluate each package.  This is time that
maintainers have already invested.

I personally have zero-interest in minimal systems.  If others want to
set USE=-* that's great for them, and if somebody wants to create a
profile that sets USE=-* and has some per-package exceptions to fix a
few things, that is also great.  If there are cases where we can do
things a little differently to make life easier on these sorts of
users, we should do that.  However, limiting IUSE defaults just to
settings minimally necessary to get a package to build just makes it
impossible to use Gentoo practically without reviewing a bazillion USE
flags.

There is no reason everybody can't have their own way, but IMO it is
much simpler to do this with a minimal profile.

-- 
Rich

Re: [gentoo-dev] Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/02/2017 09:00 PM, Sam Jorna wrote:
>
> Consider: a new user, coming from Ubuntu or Fedora or Windows, starts 
> building their system. They start installing packages they want, only to 
> find that half of the package isn't there because no USE flags were 
> enabled. They have to enable these flags for almost every package they 
> want because there's no defaults, you must manually specify anything 
> that's not a direct dependency or forced by profile.

Desktop profile!! We have a desktop profile!!! Why is the base
profile a better location for new-user-with-a-desktop defaults than the
**desktop** profile?

I'm going crazy. I give up.

Re: [gentoo-dev] Guidelines for IUSE defaults

[Sam Jorna]

On Thu, Feb 02, 2017 at 09:11:26AM -0500, Michael Orlitzky wrote:
> IUSE defaults are used in a few different ways:
> 
>   1 To ensure that critical functionality is enabled.
> 
> * Example: force the "unix" module for apache.

Why provide a flag for something that is required anyway? And if it's a 
case of "you *really* should have this, but if you want to break it, 
here's how", then why not put it in package.use.force instead? An IUSE 
default for this doesn't make sense.

>   2 To avoid an unsatisfied REQUIRED_USE by default.
> 
> * Example: having a non-empty RUBY_TARGETS by default.

This seems reasonable - two mutually exclusive options, of which one is 
preferred. That being said, I do see it as akin to 3 and 4.

>   3 To make Gentoo defaults the upstream defaults.
> 
> * Example: right now the defaults for dev-lang/php build
>   you a "normal" PHP installation.
> 
>   4 To make the default build agree with the maintainer's personal
> preferences.
> 

The way I see it, IUSE defaults are provided by the maintainer as a way 
to offer a package with "what you probably would want enabled" to 
facilitate users who either aren't interested in ricing their system or 
aren't experienced enough with Gentoo to tweak all the flags.

Consider: a new user, coming from Ubuntu or Fedora or Windows, starts 
building their system. They start installing packages they want, only to 
find that half of the package isn't there because no USE flags were 
enabled. They have to enable these flags for almost every package they 
want because there's no defaults, you must manually specify anything 
that's not a direct dependency or forced by profile.

Conversely, users who want a minimal system are ones who are much more 
likely to inspect emerge's output before committing to a build. They are 
likely more willing to tweak the flags to have the system provide only 
the things they want. Often they'll have USE="-*", accepting that 
they'll probably have to enabled a bunch of things to get their desired 
functionality.

IUSE defaults are a convenience for those either inexperienced with 
Gentoo or uncaring of cruft. Certainly maintainers should put some 
forethought into which flags they default to enabled, but I see the end 
goal as helping the users who need the help most (not to discount more 
advanced users, but they are more likely to *want* to tweak than one for 
whom this is their first CLI).

That's my two cents, at least.

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/02/2017 01:01 PM, Rich Freeman wrote:
> On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky  wrote:
>>
>> If (base == minimal), then all of the upstream defaults need to be added
>> to package.use for the upstream-defaults profile. That's bad,
> 
> I'll go further and say that it is unacceptably bad.
> 

Only if anyone wants an upstream-defaults profile. But nobody's asked
for one, in contrast with the large number of users who want minimal.


> Is there a better way we can have our cake and eat it too?  I'll admit
> that a huge package.use on the minimal profile isn't a whole lot
> better than a huge package.use on all the other profiles.

Every important upstream default is already enabled in some profile. If
dropping a particular IUSE default breaks desktop systems, then that
flag belongs enabled in the desktop profile. If it breaks every system,
then let's keep it default.


> Do we need another form of syntax in individual ebuilds to try to
> separate out the various cases you cite?  Does anybody care to
> actually suggest one?

Definitely not. I was hoping to simplify things, not complicate them. We
have a list of flags that can be enabled for each package. As a general
principle, it makes sense to either (a) disable them all by default, or
(b) enable them all by default. Having what is essentially a random
selection enabled by default for each package is chaos.


> I still think that we shouldn't encourage users to lightly deviate
> from all the upstream defaults. 

Deviating from upstream defaults is why we have USE flags in the first
place. No one really wants the upstream defaults, they want

  (nothing) + (what their profile provides) + (what they enable),

not least of all because that assumption is how they came up with the
list of flags in (what they enable) in the first place.

If dropping an IUSE default hurts some profile, then stick the default
in that profile. Nothing breaks, and it's not too much work, and we get
back to a sane system of profile inheritance rather than having every
ebuild and profile trying to XOR one another.

Re: [gentoo-dev] Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/02/2017 06:41 PM, Ian Stakenvicius wrote:
> Responding here instead of the first time it was posted, just 'cause.
> 
> On 02/02/17 06:35 PM, james wrote:
>> "
>> I'm not saying that we should have a minimal experience out-of-the-box,
>> only that the base profile should result in an effectively-minimal set
>> of USE flags. Adding IUSE defaults is essentially adding defaults to the
>> base profile."
> 
> Yes.  More specifically, it's adding these defaults without setting
> the flags globally, thereby not introducing system-wide defaults
> across all packages but only those that make sense on a per-package
> basis for that package to operate properly.
> 
> IMO this is the effectively minimal-set of use flags we should have.

I... agree? We should enable the flags that are necessary for the
package to work, and we should enable whatever is necessary to avoid
REQUIRED_USE roadblocks. That's what I started out by suggesting.

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Thu, Feb 2, 2017 at 6:28 PM, james  wrote:
> On 02/02/2017 04:05 PM, Rich Freeman wrote:
>>
>> The problem is the new user experience.  When somebody is new to
>> Gentoo and not super-knowledgeable the first thing they're going to do
>> is set up a desktop.  Now, they might not call it a desktop.  They
>> might not even run X11 on it.  But, they're basically falling into
>> that desktop user experience where whatever they do install "just
>> works" and is feature-complete.
>
> Nobody give a damn about the
> gentoo noob; that's why it is gentoo policy not to have an installer.
>

No such policy exists, as far as I'm aware.  If one does could you
cite it so that we can strike it down?

As far as I'm aware there is no Gentoo policy about hosting any
particular kind of software, as long as we can legally host it.

> I just do not see your 'either or scenario' as the only possibility.

Then let me clarify that I wasn't proposing anything as an exclusive
option.  I merely think that it makes more sense to specify default
package-specific USE flags in the packages and not in the profiles.
As I posted earlier I'm open to better ways of doing that.

> All I really need is a minimized (a least or very low set of
> packages) profile that is not so concerned with most of the upstream
> projects and the noise found therein.

Sure, and that was basically how I suggested going about it.

-- 
Rich

Re: [gentoo-dev] Guidelines for IUSE defaults

[Gordon Pettey]

On Thu, Feb 2, 2017 at 12:01 PM, Rich Freeman  wrote:

> On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky  wrote:
> >
> > If (base == minimal), then all of the upstream defaults need to be added
> > to package.use for the upstream-defaults profile. That's bad,
>
> I'll go further and say that it is unacceptably bad.
>
> > but if
> > (base == upstream-defaults), then the important IUSE defaults need to be
> > copy/pasted from our ebuilds into the minimal profile. The latter is
> > more spiritually damning =)
> >
>
> So, I'll admit I've never been one that cared a great deal about
> minimalism so I appreciate that I may not be the best one to judge
> this, so let's go ahead and embrace your statement for the purpose of
> debate.
>
> Is there a better way we can have our cake and eat it too?  I'll admit
> that a huge package.use on the minimal profile isn't a whole lot
> better than a huge package.use on all the other profiles.
>
> Do we need another form of syntax in individual ebuilds to try to
> separate out the various cases you cite?  Does anybody care to
> actually suggest one?
>
> I still think that we shouldn't encourage users to lightly deviate
> from all the upstream defaults.  There are of course legitimate
> reasons for doing so, and you and I can probably appreciate when we
> should do this, but for somebody starting out we're giving them a lot
> of rope to hang themselves with.  It is like building a kernel
> answering no to the largest number of questions possible while still
> actually building something.  I'd actually be curious as to what that
> kernel would even be capable of doing (there are a lot of fairly
> essential things you can turn off in the kernel).
>
> In the same way, we shouldn't be too quick to deviate from upstream
> defaults ourselves (#4 in your example), beyond actual integration
> work.
>
> I'll admit the current state is a bit of a compromise, but I don't
> think we should change it unless we're changing it to something
> significantly better.  This is a pretty big-impact change.
>
> --
> Rich
>

If you want to keep this kind of thing in the ebuilds, IUSE="+blah" doesn't
allow any granularity. Another variable USE_PROFILE should be added
analogue to DEPENDS:
IUSE="gnome-keyring gtk-theme kwallet pulseuadio qt-theme
annoyingUpstreamDefault"
USE_PROFILE="
desktop? ( pulseaudio )
gtk? ( gtk-theme )
gnome? ( @gtk gnome-keyring)
kde? ( @qt kwallet )
qt? ( qt-theme )
upstream? ( annoyingUpstreamDefault )
"
@ is already used for sets, so "some other use_profile's set of defined
flags" seems reasonable. It should be additive only, so no +- prefixes
needed (or allowed). If a package is emerged without any USE_PROFILE set,
you might einfo "This package supports was emerged with no use profile. It
supports blah1, blah2, and blah3. Upstream recommends blah2." USE_PROFILE
should never have any default selected by an ebuild; if a flag is required
to build, is shouldn't be a flag. You get independent behavior per package
rather than listing every single package that ever existed in
profile/package.use, package behavior actually being with the package
instead of global profiles, and you get rid of the mess of uncustomizable
IUSE="+something" everywhere that makes people like me tend to start off
every new Gentoo install with echo "USE=\"-*\"" >> /etc/portage/make.conf.
Just need to come up with sane naming convention for common possibilities
like kde, gnome, and generic desktop.

If you want upstream, USE_PROFILE="upstream". If Gentoo as an organization
wants that to be the "friendly to new user" standard, put
USE_PROFILE="upstream" in the stage3 make.conf, where those of us who want
to can simply remove or change it instead of having to nuke everything with
USE="-*". You can still use e.g. RUBY_TARGETS="+ruby21" in an ebuild if you
want a default for things that really require an at-least-one-of choice.

Then instead of default/linux/amd64/13.0/desktop/kde listing any USE flags
itself, it just sets required USE_PROFILE and lets the packages do their
thing.

Re: [gentoo-dev] Guidelines for IUSE defaults

[Daniel Campbell]

On 02/02/2017 12:35 PM, james wrote:
> On 02/02/2017 01:01 PM, Rich Freeman wrote:
>> On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky  wrote:
>>>
>>> If (base == minimal), then all of the upstream defaults need to be added
>>> to package.use for the upstream-defaults profile. That's bad,
>>
>> I'll go further and say that it is unacceptably bad.
>>
>>> but if
>>> (base == upstream-defaults), then the important IUSE defaults need to be
>>> copy/pasted from our ebuilds into the minimal profile. The latter is
>>> more spiritually damning =)
>>>
>>
>> So, I'll admit I've never been one that cared a great deal about
>> minimalism so I appreciate that I may not be the best one to judge
>> this, so let's go ahead and embrace your statement for the purpose of
>> debate.
>>
>> Is there a better way we can have our cake and eat it too?  I'll admit
>> that a huge package.use on the minimal profile isn't a whole lot
>> better than a huge package.use on all the other profiles.
>>
>> Do we need another form of syntax in individual ebuilds to try to
>> separate out the various cases you cite?  Does anybody care to
>> actually suggest one?
> 
> I think that unikernels are something everyone should be aware of
> as they purport to be the latest trend in securing all sorts of systems.
> (a brief read).
> 
> http://unikernel.org/
> 
> 
> Perhaps we should not have a 'minimal profile', as it means so many
> different things to so many different people. We have not even surveyed
> the user base...
> 
> So if we think of all the possible profiles and sub-profiles as being
> organized in a tree structure, it is better to figure out logical
> organization of all profiles, imho.
> 
> So how about profiles that are either under the embedded or basic
> 'moniker' in the profile tree.  So embedded is the least number of
> packages possible,  regardless of upstream, where folks build up from
> there to what they want as a finished system. Embedded, clusters, HPC,
> and such are compatible enough for what I'm building to be under the
> same branch of the profile tree. If other folks want their cluster works
> under the basic  part of the profile tree that is concerned with
> upstream, then  they have their part of the profile tree located there.
> 
> And the 'basic' part of the tree is similar to what we now call
> 'default' and the names build up in whatever schema those target builds
> desire, like basic+headless, basic+kde, basic+?+whatever. ?
> 
> And is there any reason, if necessary that other needs cannot be
> branched off, as necessary form the profile tree?  Perhaps the main root
> is a state diagram of what is need and has links to  relevant documents.
> That way the profile tree is a live system that can  be enhance or
> modified to serve all of Gentoo's diverse visions.

That's an awful lot of change for only slight benefit. The mixin idea
that mgorny's been proposing may become a great way for people to state
their needs explicitly in something that profiles are able to handle,
once that work is finished. I believe Funtoo uses this extensively, and
they might be worth contacting to see how we can best use them for our
needs as well, assuming the design is the same.

> 
> 
>> I still think that we shouldn't encourage users to lightly deviate
>> from all the upstream defaults.  There are of course legitimate
>> reasons for doing so, and you and I can probably appreciate when we
>> should do this, but for somebody starting out we're giving them a lot
>> of rope to hang themselves with.
> 
> This is only the case because profiles are in general in a mess and
> there are little in the way of conventions. What is so sacrosanct about
> upstream for a truly embedded gentoo system or a gentoo based IoT
> device? How many of the gentoo-embedded devs even bother to read
> gentoo-dev? Your vision seems to me to be tainted by the major distros
> and their visions, not be impolite, but they are way off course for
> secure systems, embedded systems, IoT, HPC and numerous other active
> areas of Linux, imho.
> 
> 
> Think about it, if upstream is so brilliant, and has our needs 'at
> heart' then why have not the kernel-geniuses bothered to build a
> logical, coherent semantic for kernel configurations, management,
> security testing and such?  If fact, if I were to be critical of
> upstream, I'd say those and many other issues should have been addressed
> before the adventures of systemd were dictated upon the larger user
> base. Upstream is an 'ad-hoc' mess, in the old days we called such
> entities a clusterF*.

Profiles may be a bit of a mess. I'm not qualified to determine that
since I don't touch profiles, but the brief browsing I've done indicates
that *some* care was put into it, or there wouldn't be such a large
profile tree.

The thing about Gentoo is that no single use case rules all, but as a
distribution we kinda owe it to the greater user audience to adopt
upstream defaults. The entire point of USE 

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ian Stakenvicius]

Responding here instead of the first time it was posted, just 'cause.

On 02/02/17 06:35 PM, james wrote:
> "
> I'm not saying that we should have a minimal experience out-of-the-box,
> only that the base profile should result in an effectively-minimal set
> of USE flags. Adding IUSE defaults is essentially adding defaults to the
> base profile."


Yes.  More specifically, it's adding these defaults without setting
the flags globally, thereby not introducing system-wide defaults
across all packages but only those that make sense on a per-package
basis for that package to operate properly.

IMO this is the effectively minimal-set of use flags we should have.
All of these flags can be easily overridden for a more minimalist, and
IMO they should definitely attempt to avoid any REQUIRED_USE like
conflicts (that is, two packages collide because their IUSE-defaults
make dependencies conflict).  But no less than that should be what the
base package provides, IMO.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[james]

On 02/02/2017 04:40 PM, David Seifert wrote:

On Thu, 2017-02-02 at 15:35 -0500, james wrote:

On 02/02/2017 01:01 PM, Rich Freeman wrote:

On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky 
wrote:


If (base == minimal), then all of the upstream defaults need to
be added
to package.use for the upstream-defaults profile. That's bad,


I'll go further and say that it is unacceptably bad.


but if
(base == upstream-defaults), then the important IUSE defaults
need to be
copy/pasted from our ebuilds into the minimal profile. The latter
is
more spiritually damning =)



So, I'll admit I've never been one that cared a great deal about
minimalism so I appreciate that I may not be the best one to judge
this, so let's go ahead and embrace your statement for the purpose
of
debate.

Is there a better way we can have our cake and eat it too?  I'll
admit
that a huge package.use on the minimal profile isn't a whole lot
better than a huge package.use on all the other profiles.

Do we need another form of syntax in individual ebuilds to try to
separate out the various cases you cite?  Does anybody care to
actually suggest one?


I think that unikernels are something everyone should be aware of
as they purport to be the latest trend in securing all sorts of
systems.
(a brief read).

http://unikernel.org/


Perhaps we should not have a 'minimal profile', as it means so many
different things to so many different people. We have not even
surveyed
the user base...

So if we think of all the possible profiles and sub-profiles as being
organized in a tree structure, it is better to figure out logical
organization of all profiles, imho.

So how about profiles that are either under the embedded or basic
'moniker' in the profile tree.  So embedded is the least number of
packages possible,  regardless of upstream, where folks build up
from
there to what they want as a finished system. Embedded, clusters,
HPC,
and such are compatible enough for what I'm building to be under the
same branch of the profile tree. If other folks want their cluster
works
under the basic  part of the profile tree that is concerned with
upstream, then  they have their part of the profile tree located
there.

And the 'basic' part of the tree is similar to what we now call
'default' and the names build up in whatever schema those target
builds
desire, like basic+headless, basic+kde, basic+?+whatever. ?

And is there any reason, if necessary that other needs cannot be
branched off, as necessary form the profile tree?  Perhaps the main
root
is a state diagram of what is need and has links to  relevant
documents.
That way the profile tree is a live system that can  be enhance or
modified to serve all of Gentoo's diverse visions.



I still think that we shouldn't encourage users to lightly deviate
from all the upstream defaults.  There are of course legitimate
reasons for doing so, and you and I can probably appreciate when we
should do this, but for somebody starting out we're giving them a
lot
of rope to hang themselves with.


This is only the case because profiles are in general in a mess and
there are little in the way of conventions. What is so sacrosanct
about
upstream for a truly embedded gentoo system or a gentoo based IoT
device? How many of the gentoo-embedded devs even bother to read
gentoo-dev? Your vision seems to me to be tainted by the major
distros
and their visions, not be impolite, but they are way off course for h
ttp://www.easyjet.com/en/
secure systems, embedded systems, IoT, HPC and numerous other active
areas of Linux, imho.


Think about it, if upstream is so brilliant, and has our needs 'at
heart' then why have not the kernel-geniuses bothered to build a
logical, coherent semantic for kernel configurations, management,
security testing and such?  If fact, if I were to be critical of
upstream, I'd say those and many other issues should have been
addressed
before the adventures of systemd were dictated upon the larger user
base. Upstream is an 'ad-hoc' mess, in the old days we called such
entities a clusterF*.


So those of us going back to minimal and basics and such venues, even
with clusters, could not care less about Mozilla, systemd and
thousands
of other upstream folks  that have lost their pathway forward.
(deepest
apologies, but I have very strong feelings about "upstream*".


Many of the profiles in this and other recent threads, are just 'ad-
hoc'
naming structures and locations, and that historical flexibility
extend
to the devs is fantastic. This enhance/cleaning need of gentoo
profiles
needs to be well thought out and as flexible semantically as
possible.


It is absolutely a superior approach to not care at all what
upstream
does, to provide a pathway for embedded gentoo. That is a
fundamental
characteristic of what an embedded system is. Thanke the code, purge
90+ percent of this, and then install it on a embedded system so
only what is needed is encluded. On a distro, you can pile on tons
of 

Re: [gentoo-dev] Guidelines for IUSE defaults

[james]

On 02/02/2017 04:05 PM, Rich Freeman wrote:

On Thu, Feb 2, 2017 at 3:35 PM, james  wrote:



I think that unikernels are something everyone should be aware of
as they purport to be the latest trend in securing all sorts of systems.
(a brief read).



Not really for all sorts, more for servers.  Otherwise I get it, and
at this point now that I run almost everything in containers I tend to
be more inclined to run different distros in those containers.


This is only the case because profiles are in general in a mess and there
are little in the way of conventions. What is so sacrosanct about upstream
for a truly embedded gentoo system or a gentoo based IoT device?


Nothing, in that space.

The problem is the new user experience.  When somebody is new to
Gentoo and not super-knowledgeable the first thing they're going to do
is set up a desktop.  Now, they might not call it a desktop.  They
might not even run X11 on it.  But, they're basically falling into
that desktop user experience where whatever they do install "just
works" and is feature-complete.


Wow, I'm shocked. Perhaps you have forgotten that is was "I" that 
bemoaned and protested ad nauseam for a simple, basic desktop

for the noob moving to or just testing gentoo? Needless to say the
majority of long term folks on gentoo-user, prefer to run those noobs 
off. (Remember I was on gentoo-user for 12 years, by the hour.)

Now our gentoo distro is catering and concerned about these folks?
(excuse me but I haft to roll around on the floor a bit to get some
belly laughter out) ok, I'm back now. Nobody give a damn about the
gentoo noob; that's why it is gentoo policy not to have an installer.




It is true that we also attract advanced users who are looking for
something different.  They have no issues getting any distro to dance
for them, and they're picking Gentoo because it is best suited for
their specific need.  These users are much more likely to be
interested in minimal configurations, embedded systems, the hardened
profiles, and so on.


This pool is growing and many are contributing hardened on top
of minimal very very cool.


However, the problem is that if we optimize mainly for the second
group we basically lose the first group entirely, and I suspect that
is overall going to be the bigger group.


Nope, sorry, I have to disagree. Please explain why we cannot, in the 
profiles, support both groups. The (minimal) embedded profile pathway 
need not be mentioned in the handbook. But, perhaps in the 
gentoo-embedded-handbook it could be introduced ? If the embedded devs are

offended, then it could be unser it's own profile:: spartan, monopod,
minimized or any self identifying moniker.



If what you want is a "unikernel profile" for Gentoo then you're going
to be changing a LOT of assumptions.


Oops, hit the brakes! Unikernels the way that unikerel.org describes
them is more of a enhanced state machine boot_code or an executive
or a linux kernel plus one lib. Sorry but that's not the only vision
and mine is to build highly targeted 'minimal' gentoo systems that can 
dynamically shed and load new frameworks (groups of packages and codes 
and such) on top of the 'default set' or embedded set of packages. So it 
can become a full blown mail server or a singular monotonic device, just 
sniffing ethernet, without a reboot. I'm betting the farm that my vision 
of minimal/embedded gentoo will be far more successful than those folks 
pushing proprietary Unikernel products. Still the generic moniker 
'unikernel' is the closest commonly used moniker to where I'm driving 
too, I so 'lifted' it from those folks. Goals are similar but mine is a 
minimized gentoo, at it's core and dynamically flexible without reboot.





Forget openrc vs systemd, there
is no reason to have any init implementation on the thing.  Forget
linux vs bsd, there is also no reason to have a kernel in a container.
We don't need any editor because you're probably going to do any
config file editing from outside of the container.  And that @system
set that has all that bootstrapping stuff is probably way overkill if
all you ultimately need is a single package to work (and maybe not all
of that package).  Heck, your overall install approach also should be
questioned.  Rather than build your unikernel from inside its own
container, you should be building from a more complete image and just
installing the minimum RDEPENDs in the production container (as with
catalyst or the chromiumos builds).  And you probably wouldn't be
upgrading such things in place either, you'd just be creating newer
instances and cutting over from the old.


I agree with you on this, absolutely. But you are far off from my
branch of the profile tree and my pathway forward, so it's accurate
but completely uncharacteristic to what I'm developing.



I don't question that it would be great for Gentoo to support all of
this stuff.  I just think that we need to be careful not to 

Re: [gentoo-dev] Guidelines for IUSE defaults

[Dirkjan Ochtman]

On Thu, Feb 2, 2017 at 4:36 PM, Michael Orlitzky  wrote:
> I'm not saying that we should have a minimal experience out-of-the-box,
> only that the base profile should result in an effectively-minimal set
> of USE flags. Adding IUSE defaults is essentially adding defaults to the
> base profile. Why does dev-java/icedtea try to pull in GTK (and thus X)
> on a headless server? That stuff belongs in a desktop profile, not in
> the base one.
>
> I don't think minimal should be our default, but it should be
> *possible*. It practically isn't so long as people mix uses #1, #3, and
> #4. I guess I would also be happy if we outlawed use #1 so that USE="-*"
> would be supported. In any case, we should document how to use them.
> Having them mean four different things causes confusion.

Like others, I think that having IUSE defaults as reflecting upstream
makes much more sense, because it makes more sense to put upstream's
nuances in the ebuilds than in some of our profiles. I've run systems
with -* before, and found it to work okay. These days I have a
somewhat more minimal set of disabled USE flags in make.conf, which
seems to work fine for my somewhat-minimal headless server, too.

Anyway, I don't know how prevalent your #1 is, but making -* more
supported seems more attractive to me than the other options.

Cheers,

Dirkjan

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Thu, Feb 2, 2017 at 3:35 PM, james  wrote:

>
> I think that unikernels are something everyone should be aware of
> as they purport to be the latest trend in securing all sorts of systems.
> (a brief read).
>

Not really for all sorts, more for servers.  Otherwise I get it, and
at this point now that I run almost everything in containers I tend to
be more inclined to run different distros in those containers.

> This is only the case because profiles are in general in a mess and there
> are little in the way of conventions. What is so sacrosanct about upstream
> for a truly embedded gentoo system or a gentoo based IoT device?

Nothing, in that space.

The problem is the new user experience.  When somebody is new to
Gentoo and not super-knowledgeable the first thing they're going to do
is set up a desktop.  Now, they might not call it a desktop.  They
might not even run X11 on it.  But, they're basically falling into
that desktop user experience where whatever they do install "just
works" and is feature-complete.

It is true that we also attract advanced users who are looking for
something different.  They have no issues getting any distro to dance
for them, and they're picking Gentoo because it is best suited for
their specific need.  These users are much more likely to be
interested in minimal configurations, embedded systems, the hardened
profiles, and so on.

However, the problem is that if we optimize mainly for the second
group we basically lose the first group entirely, and I suspect that
is overall going to be the bigger group.

If what you want is a "unikernel profile" for Gentoo then you're going
to be changing a LOT of assumptions.  Forget openrc vs systemd, there
is no reason to have any init implementation on the thing.  Forget
linux vs bsd, there is also no reason to have a kernel in a container.
We don't need any editor because you're probably going to do any
config file editing from outside of the container.  And that @system
set that has all that bootstrapping stuff is probably way overkill if
all you ultimately need is a single package to work (and maybe not all
of that package).  Heck, your overall install approach also should be
questioned.  Rather than build your unikernel from inside its own
container, you should be building from a more complete image and just
installing the minimum RDEPENDs in the production container (as with
catalyst or the chromiumos builds).  And you probably wouldn't be
upgrading such things in place either, you'd just be creating newer
instances and cutting over from the old.

I don't question that it would be great for Gentoo to support all of
this stuff.  I just think that we need to be careful not to destroy
the experience of somebody who just wants a "typical" install in order
to do it.  Somebody who doesn't want to take the time to tweak how
their java implementation works probably wants the default install to
be something that meets the Oracle standard.  Now, somebody who is
into tailoring can look at their application and tweak the living
daylights out of it, but that shouldn't be what you get when you run
"emerge icedtea" or whatever.

Sure, you could do all that with a profile, but the problem is:
1.  Maintainers aren't going to necessarily invest in that profile.
2.  New users won't necessarily use that new profile.

And when those things doesn't happen users look at Gentoo as the OS
that nothing works right on.

-- 
Rich

Re: [gentoo-dev] Guidelines for IUSE defaults

[james]

On 02/02/2017 01:01 PM, Rich Freeman wrote:

On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky  wrote:


If (base == minimal), then all of the upstream defaults need to be added
to package.use for the upstream-defaults profile. That's bad,


I'll go further and say that it is unacceptably bad.


but if
(base == upstream-defaults), then the important IUSE defaults need to be
copy/pasted from our ebuilds into the minimal profile. The latter is
more spiritually damning =)



So, I'll admit I've never been one that cared a great deal about
minimalism so I appreciate that I may not be the best one to judge
this, so let's go ahead and embrace your statement for the purpose of
debate.

Is there a better way we can have our cake and eat it too?  I'll admit
that a huge package.use on the minimal profile isn't a whole lot
better than a huge package.use on all the other profiles.

Do we need another form of syntax in individual ebuilds to try to
separate out the various cases you cite?  Does anybody care to
actually suggest one?


I think that unikernels are something everyone should be aware of
as they purport to be the latest trend in securing all sorts of systems.
(a brief read).

http://unikernel.org/


Perhaps we should not have a 'minimal profile', as it means so many 
different things to so many different people. We have not even surveyed

the user base...

So if we think of all the possible profiles and sub-profiles as being
organized in a tree structure, it is better to figure out logical 
organization of all profiles, imho.


So how about profiles that are either under the embedded or basic 
'moniker' in the profile tree.  So embedded is the least number of
packages possible,  regardless of upstream, where folks build up from 
there to what they want as a finished system. Embedded, clusters, HPC, 
and such are compatible enough for what I'm building to be under the 
same branch of the profile tree. If other folks want their cluster works 
under the basic  part of the profile tree that is concerned with 
upstream, then  they have their part of the profile tree located there.


And the 'basic' part of the tree is similar to what we now call 
'default' and the names build up in whatever schema those target builds

desire, like basic+headless, basic+kde, basic+?+whatever. ?

And is there any reason, if necessary that other needs cannot be 
branched off, as necessary form the profile tree?  Perhaps the main root

is a state diagram of what is need and has links to  relevant documents.
That way the profile tree is a live system that can  be enhance or 
modified to serve all of Gentoo's diverse visions.




I still think that we shouldn't encourage users to lightly deviate
from all the upstream defaults.  There are of course legitimate
reasons for doing so, and you and I can probably appreciate when we
should do this, but for somebody starting out we're giving them a lot
of rope to hang themselves with.


This is only the case because profiles are in general in a mess and 
there are little in the way of conventions. What is so sacrosanct about 
upstream for a truly embedded gentoo system or a gentoo based IoT 
device? How many of the gentoo-embedded devs even bother to read
gentoo-dev? Your vision seems to me to be tainted by the major distros 
and their visions, not be impolite, but they are way off course for 
secure systems, embedded systems, IoT, HPC and numerous other active 
areas of Linux, imho.



Think about it, if upstream is so brilliant, and has our needs 'at 
heart' then why have not the kernel-geniuses bothered to build a 
logical, coherent semantic for kernel configurations, management, 
security testing and such?  If fact, if I were to be critical of 
upstream, I'd say those and many other issues should have been addressed 
before the adventures of systemd were dictated upon the larger user 
base. Upstream is an 'ad-hoc' mess, in the old days we called such 
entities a clusterF*.



So those of us going back to minimal and basics and such venues, even
with clusters, could not care less about Mozilla, systemd and thousands
of other upstream folks  that have lost their pathway forward. (deepest 
apologies, but I have very strong feelings about "upstream*".



Many of the profiles in this and other recent threads, are just 'ad-hoc' 
naming structures and locations, and that historical flexibility extend 
to the devs is fantastic. This enhance/cleaning need of gentoo profiles 
needs to be well thought out and as flexible semantically as possible.



It is absolutely a superior approach to not care at all what upstream 
does, to provide a pathway for embedded gentoo. That is a fundamental 
characteristic of what an embedded system is. Thanke the code, purge

90+ percent of this, and then install it on a embedded system so
only what is needed is encluded. On a distro, you can pile on tons
of uncessary codes, for convenience and not care, but embedded,
it does matter. That is why so 

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky  wrote:
>
> If (base == minimal), then all of the upstream defaults need to be added
> to package.use for the upstream-defaults profile. That's bad,

I'll go further and say that it is unacceptably bad.

> but if
> (base == upstream-defaults), then the important IUSE defaults need to be
> copy/pasted from our ebuilds into the minimal profile. The latter is
> more spiritually damning =)
>

So, I'll admit I've never been one that cared a great deal about
minimalism so I appreciate that I may not be the best one to judge
this, so let's go ahead and embrace your statement for the purpose of
debate.

Is there a better way we can have our cake and eat it too?  I'll admit
that a huge package.use on the minimal profile isn't a whole lot
better than a huge package.use on all the other profiles.

Do we need another form of syntax in individual ebuilds to try to
separate out the various cases you cite?  Does anybody care to
actually suggest one?

I still think that we shouldn't encourage users to lightly deviate
from all the upstream defaults.  There are of course legitimate
reasons for doing so, and you and I can probably appreciate when we
should do this, but for somebody starting out we're giving them a lot
of rope to hang themselves with.  It is like building a kernel
answering no to the largest number of questions possible while still
actually building something.  I'd actually be curious as to what that
kernel would even be capable of doing (there are a lot of fairly
essential things you can turn off in the kernel).

In the same way, we shouldn't be too quick to deviate from upstream
defaults ourselves (#4 in your example), beyond actual integration
work.

I'll admit the current state is a bit of a compromise, but I don't
think we should change it unless we're changing it to something
significantly better.  This is a pretty big-impact change.

-- 
Rich

Re: [gentoo-dev] Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/02/2017 12:23 PM, Walter Dnes wrote:
> On Thu, Feb 02, 2017 at 09:11:26AM -0500, Michael Orlitzky wrote
> 
>>   2 To avoid an unsatisfied REQUIRED_USE by default.
>>
>> * Example: having a non-empty RUBY_TARGETS by default.
> 
>   What's wrong with having emerge spit out an error message, and telling
> the user that they need to set a flag to one of 2-or-more options?
> 

If everything is already sorted out on your machine, and the package
you're trying to install is something you care about, then you're right:
I think most people would like to be prompted and make a choice.

But imagine a fresh install, where you've set your USE flags and are
about to do the final emerge -e @world. It's going to stop and prompt
you 1,000 times to e.g. pick a ruby implementation, when I don't want
ruby and don't care about ruby but it just happens to be used in the
build system for webkit-gtk. If 90% of the prompts are for things like
that, people will start defenestrating their Gentoo systems.

Re: [gentoo-dev] Guidelines for IUSE defaults

[Walter Dnes]

On Thu, Feb 02, 2017 at 09:11:26AM -0500, Michael Orlitzky wrote

>   2 To avoid an unsatisfied REQUIRED_USE by default.
> 
> * Example: having a non-empty RUBY_TARGETS by default.

  What's wrong with having emerge spit out an error message, and telling
the user that they need to set a flag to one of 2-or-more options?

>   4 To make the default build agree with the maintainer's personal
> preferences.
> 
> * Example: enabling hpn in net-misc/openssh by default.

  Another example is IPV6 which most people do not yet have from their
ISP as a regular service.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/02/2017 11:08 AM, Rich Freeman wrote:
> 
> Which is simpler, a minimal profile that sets USE=-* and then lists a
> few exceptions where that breaks in package.use, or an upstream
> defaults profile (which becomes the basis for all the other profiles)
> that has a 5000 line package.use file that specifies the upstream
> defaults for every package in the repository?
> 

It's honestly hard to say. I see your point, but "a few exceptions"
might not be so few. Every IUSE default that

  (1) enables something critical, or
  (2) enables a default choice for a REQUIRED_USE constraint

would need to be added back to the minimal profile. And of course the
reason I started this thread is that those two usages are common. I
clearly had the "minimal base" profile in mind, but the fact that (1)
and (2) are used throughout the tree creates problems for any minimal
profile, even is the base profile is "upstream defaults."

If (base == minimal), then all of the upstream defaults need to be added
to package.use for the upstream-defaults profile. That's bad, but if
(base == upstream-defaults), then the important IUSE defaults need to be
copy/pasted from our ebuilds into the minimal profile. The latter is
more spiritually damning =)

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Thu, Feb 2, 2017 at 10:59 AM, Michael Orlitzky  wrote:
>
> The upstream defaults would
> build on top of the minimal base profile, in plain old package.use. In
> the profile is exactly where the upstream defaults belong in an
> "upstream defaults" profile.
>
> I think (base == minimal) is the simpler way to allow both possibilities.
>

Which is simpler, a minimal profile that sets USE=-* and then lists a
few exceptions where that breaks in package.use, or an upstream
defaults profile (which becomes the basis for all the other profiles)
that has a 5000 line package.use file that specifies the upstream
defaults for every package in the repository?

Profiles like desktop/server/etc seem far more likely to end up being
based on the upstream defaults profile than on the minimal profile, so
calling the minimal profile "base" also seems a bit wrong.

It just seems easier to start with an elegantly created set of
reasonable defaults and apply a sledgehammer to it, than start with a
barren wasteland and then try to carefully create a lot of detail on
top.

Also, as has been pointed out in the other subthread, a lot of this
stuff becomes use-case-specific.  I get that people don't want stuff
they don't want, but it often isn't actually based on whether they're
running desktop vs server or embedded vs traditional and so on (which
is also the issue with server profiles in general).  If you want to go
down that road I think mix-ins make far more sense so that you can
have a million very-specific use cases addressed with specific
solutions rather than having everybody arguing endlessly about whether
a "server" needs imagemagick or apache.

-- 
Rich

Re: [gentoo-dev] Guidelines for IUSE defaults

[james]

On 02/02/2017 10:06 AM, Kristian Fiskerstrand wrote:

On 02/02/2017 03:11 PM, Michael Orlitzky wrote:

Can we discourage IUSE defaults except for #1 and #2? I'm equally guilty
of #3 and #4, but I now regret them. I would also like to see
explanations in metadata.xml of why +flags are on by default.


This presumes that the goal is minimal system in all cases, rather than
a good user experience for inter alia a desktop system or a
server-system. If a user requires a minimal system for whatever reason
(s)he is likely more prepared to understand the choices than the average
user.


Not so sure about his postulate.

As one who defaults to minimal systems (yes even on a 8-core 32G ram 
system), I'd like to offer a bit of insight. Please keep in mind  that 
in my experiences, there are probably many more folks creating ebuilds
than gentoo has devs; so as logical and streamlined and coherent as 
possible means a necessary focal point is the minimized gentoo system build.


Some folks need a minimal install because of their hardware constraints.

Some folks want a minimal install because statistically that's the 
easiest way to get a new (rolling) distro working, especially minus a 
heavy WM, like KDE. Due to a lack of a streamlined installer processes 
for gentoo, there is a lot of 'monkey see monkey do' approaches to 
repetitively installing gentoo in the wild, so a minimal focus is 
better. (KISS is king).


Some folks want a minimal install, because it's fairly trivial (for 
identical platformed system) to then copy over bin packages or compile 
in  additional packages (via the world file) and make the system 
whatever they want it to be. It can also be returned to a minimal state, 
by just removing these secondary packages that converted the minimal 
system into something more full featured.


Some folks want a minimal arm system that is in the footprint of a small
(arm-based) laptop, so it is quite similar to  Single Board Computer arm 
systems  as possible; ultimately trying to keep a variety of arm systems 
as similar as possible.


Some folks have a variety of embedded gentoo systems, and the closer the
minimal system is to being identical (via package sets) the more logical 
their schema  can be on management (think IoT).



I could go on and on all all, clusters, firewalls kiosk etc etc. My 
point is a minimal system is the foundational building block for gentoo 
and as such it is like a construction dock for building up all sorts, if 
not all gentoo systems.


How this affects re-organization of documentation on IUSE and related 
issues is of great curiosity to me. So, when my work is complete (or at 
least enough to share) there shall be many stage-4 minimal gentoo images 
to install from and go from there. So as much as all issues can be 
minimized, standardized, documented and look like other arches, the "mo 
better" imo.



hth,
James

Re: [gentoo-dev] Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/02/2017 10:52 AM, Rich Freeman wrote:
> On Thu, Feb 2, 2017 at 10:36 AM, Michael Orlitzky  wrote:
>>
>> Why does dev-java/icedtea try to pull in GTK (and thus X)
>> on a headless server? That stuff belongs in a desktop profile, not in
>> the base one.
> 
> The base profile isn't "headless server" - it is just generic.

If this is how everyone is treating it, then we should at least document
that fact...


> The problem is that if you treat the base profile as "minimal" then
> you lose the ability to maintain an upstream-default profile (unless
> you end up with a huge package.use.force/mask file which IMO is the
> wrong place to put stuff like this).

Why would you need package.use.force/mask? The upstream defaults would
build on top of the minimal base profile, in plain old package.use. In
the profile is exactly where the upstream defaults belong in an
"upstream defaults" profile.

I think (base == minimal) is the simpler way to allow both possibilities.

Re: [gentoo-dev] Guidelines for IUSE defaults

[James Le Cuirot]

On Thu, 2 Feb 2017 10:36:51 -0500
Michael Orlitzky  wrote:

> On 02/02/2017 10:06 AM, Kristian Fiskerstrand wrote:
> > On 02/02/2017 03:11 PM, Michael Orlitzky wrote:  
> >> Can we discourage IUSE defaults except for #1 and #2? I'm equally
> >> guilty of #3 and #4, but I now regret them. I would also like to
> >> see explanations in metadata.xml of why +flags are on by default.  
> > 
> > This presumes that the goal is minimal system in all cases, rather
> > than a good user experience for inter alia a desktop system or a
> > server-system. If a user requires a minimal system for whatever
> > reason (s)he is likely more prepared to understand the choices than
> > the average user.
> 
> I'm not saying that we should have a minimal experience
> out-of-the-box, only that the base profile should result in an
> effectively-minimal set of USE flags. Adding IUSE defaults is
> essentially adding defaults to the base profile. Why does
> dev-java/icedtea try to pull in GTK (and thus X) on a headless
> server? That stuff belongs in a desktop profile, not in the base one.

I can appreciate the frustration with icedtea. It's complicated by the
fact that I made it a somewhat negative USE flag, headless-awt. This
decision wasn't taken lightly. USE=X didn't really make sense any more
so I changed it to USE=awt but upstream, who does most of the ebuild
work, objected on the basis that AWT is always present, even on
headless systems. He wanted USE=headless as that is the commonly used
term but there was also JavaFX to consider so I compromised with
headless-awt. There was the expected handful of complaints from USE=-*
users initially but I haven't heard anything regarding this in a long
time. I suppose I could enable headless-awt by default and disable it
in the desktop profile but I suspect it'll still trip somebody up.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Thu, Feb 2, 2017 at 10:36 AM, Michael Orlitzky  wrote:
>
> Why does dev-java/icedtea try to pull in GTK (and thus X)
> on a headless server? That stuff belongs in a desktop profile, not in
> the base one.

The base profile isn't "headless server" - it is just generic.

Somebody could create a headless server profile that set USE=-X and
the necessary tweaks when necessary to handle specific packages.
Having mix-ins would help with this by reducing the costs of adding
profiles so that we can offer more choices like this.

Users can of course set USE=-* if they really want a minimal system,
and build up from there.  However, a minimal profile would probably be
a better solution if somebody wanted to create one.

The problem is that if you treat the base profile as "minimal" then
you lose the ability to maintain an upstream-default profile (unless
you end up with a huge package.use.force/mask file which IMO is the
wrong place to put stuff like this).  I think that upstream-defaults
is a more sensible base than something intended to be minimal.  It is
far easier to let all the packages specify defaults individually and
then make large-scale adjustments (up or down) to these, than to try
to achieve a "default" position from one that just has everything
turned off.

-- 
Rich

Re: [gentoo-dev] Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/02/2017 09:56 AM, Ian Stakenvicius wrote:
> 
>> On Feb 2, 2017, at 9:11 AM, Michael Orlitzky 
>> wrote:
>> 
>> IUSE defaults are used in a few different ways:
>> 
>> 1 To ensure that critical functionality is enabled.
>> 
>> * Example: force the "unix" module for apache.
>> 
> 
> This is not what IUSE defaults are for, this should be done with
> package.use{,.stable}.{mask,force} in profiles.  If functionality is
> critical then there (A) shouldn't be a use flag, or (B) shouldn't be
> a way for USE= in make.conf to disable it.
> 

If we adopted this policy, then USE="-*" would no longer be guaranteed
to break the system. It does still ignore your profile defaults, though,
which presumably are important (e.g. for hardened). So we're still left
with no way for me to turn off everyone's pet USE flags and keep my
system working.

Re: [gentoo-dev] Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/02/2017 10:06 AM, Kristian Fiskerstrand wrote:
> On 02/02/2017 03:11 PM, Michael Orlitzky wrote:
>> Can we discourage IUSE defaults except for #1 and #2? I'm equally guilty
>> of #3 and #4, but I now regret them. I would also like to see
>> explanations in metadata.xml of why +flags are on by default.
> 
> This presumes that the goal is minimal system in all cases, rather than
> a good user experience for inter alia a desktop system or a
> server-system. If a user requires a minimal system for whatever reason
> (s)he is likely more prepared to understand the choices than the average
> user.
> 

I'm not saying that we should have a minimal experience out-of-the-box,
only that the base profile should result in an effectively-minimal set
of USE flags. Adding IUSE defaults is essentially adding defaults to the
base profile. Why does dev-java/icedtea try to pull in GTK (and thus X)
on a headless server? That stuff belongs in a desktop profile, not in
the base one.

I don't think minimal should be our default, but it should be
*possible*. It practically isn't so long as people mix uses #1, #3, and
#4. I guess I would also be happy if we outlawed use #1 so that USE="-*"
would be supported. In any case, we should document how to use them.
Having them mean four different things causes confusion.

Re: [gentoo-dev] Guidelines for IUSE defaults

[James Le Cuirot]

On Thu, 2 Feb 2017 16:06:02 +0100
Kristian Fiskerstrand  wrote:

> On 02/02/2017 03:11 PM, Michael Orlitzky wrote:
> > Can we discourage IUSE defaults except for #1 and #2? I'm equally
> > guilty of #3 and #4, but I now regret them. I would also like to see
> > explanations in metadata.xml of why +flags are on by default.  
> 
> This presumes that the goal is minimal system in all cases, rather
> than a good user experience for inter alia a desktop system or a
> server-system. If a user requires a minimal system for whatever reason
> (s)he is likely more prepared to understand the choices than the
> average user.

Exactly what I was going to say.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] Guidelines for IUSE defaults

[Kristian Fiskerstrand]

On 02/02/2017 03:11 PM, Michael Orlitzky wrote:
> Can we discourage IUSE defaults except for #1 and #2? I'm equally guilty
> of #3 and #4, but I now regret them. I would also like to see
> explanations in metadata.xml of why +flags are on by default.

This presumes that the goal is minimal system in all cases, rather than
a good user experience for inter alia a desktop system or a
server-system. If a user requires a minimal system for whatever reason
(s)he is likely more prepared to understand the choices than the average
user.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ian Stakenvicius]

> On Feb 2, 2017, at 9:11 AM, Michael Orlitzky  wrote:
> 
> IUSE defaults are used in a few different ways:
> 
>  1 To ensure that critical functionality is enabled.
> 
>* Example: force the "unix" module for apache.
> 

This is not what IUSE defaults are for, this should be done with 
package.use{,.stable}.{mask,force} in profiles.  If functionality is critical 
then there (A) shouldn't be a use flag, or (B) shouldn't be a way for USE= in 
make.conf to disable it.