[gentoo-dev] Guidelines for IUSE defaults

[gentoo-dev] Guidelines for IUSE defaults

[Michael Orlitzky]

IUSE defaults are used in a few different ways:

  1 To ensure that critical functionality is enabled.

    * Example: force the "unix" module for apache.

  2 To avoid an unsatisfied REQUIRED_USE by default.

    * Example: having a non-empty RUBY_TARGETS by default.

  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.

    * Example: enabling hpn in net-misc/openssh by default.


We don't have a policy for how to use them, so we get all four in the
tree. I don't think there are any downsides to #1.

The downside to #2 is that the default choice may be wrong, but the
benefit outweighs that. For a given package, the user either cares about
the USE flags or he doesn't (if it's some deep dependency). Both cases
turn out fine in #2.

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.

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ian Stakenvicius]

> On Feb 2, 2017, at 9:11 AM, Michael Orlitzky <mjo@gentoo.org> 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.

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 <mjo@gentoo.org>
>> 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.

[gentoo-dev] Re: Guidelines for IUSE defaults

[Duncan]

Michael Orlitzky posted on Thu, 02 Feb 2017 10:49:41 -0500 as excerpted:

> On 02/02/2017 09:56 AM, Ian Stakenvicius wrote:
>> 
>>> On Feb 2, 2017, at 9:11 AM, Michael Orlitzky <mjo@gentoo.org>
>>> 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.

If USE="-*" is a guarantee of a broken system, it's a pretty weak one.  
In fact, so is flying with an empty @system (everything in the profile 
negated), as I do both of the above.

And in fact, my gentoo-based-admin life has been far simpler since I set 
it up that way.  =:^)

The biggest benefit of USE="-*" is that I no longer have to worry about 
investigating the "why" of USE flag changes when I change to a different 
profile, or when devs change my existing profile out from under me.  I 
have a set of USE flags I've decided I want (or need for long-term-
installed stuff like kde), and all packages that don't work with that 
default -- for instance, packages that required-use qt4 XOR qt5, already 
have their package.use setup as appropriate.

Otherwise, when I upgrade to a new profile, as I've needed to do several 
times over the nearing a decade and a half I've been running the same 
original installation rolling-update gentoo on rolling-update hardware, I 
have to do a bunch of research on all the USE flags that changed and how 
they affect my existing installation due to --newuse.  This way, that was 
all managed at the time I encountered the original USE flag conflict, and 
the profile I choose doesn't mess with my USE flags at all except via 
forces (which I can override if I have to, but I haven't had to, a 
testament to the wisely conservative usage of forced-USE).

Of course, I can and do still use the USE flags set in a profile as a 
guide, and that was a tremendous help in the kde-apps5/frameworks5/plasma5 
upgrade process despite the fact that I couldn't actually use the profile 
designed for that.

The biggest weakness, meanwhile, is that with USE="-*" there's no easy 
way to actually see what a package's USE-defaults are, without actually 
opening up the ebuild (or at least grepping) to see.  I've often wished 
there was some way to denote the default-on flags in emerge --pretend/--
ask so I could see what they are on a new package, and investigate why if 
necessary, but I understand the problem of a limited available symbol-
space, and actually looking in the ebuild isn't /horribly/ hard... as 
long as there's multiple terminals available to do it in, without 
unnecessarily canceling the --ask output that took so long to appear.

Of course it would be a bit different if I could actually use a profile 
with all the bits I needed, nomultilib, systemd, plasma, amd64, 
primarily.  But until mixins, nomultilib generally means at least some of 
the other stuff isn't available in a profile, so I gotta simply pick the 
nomultilib profile that best matches and check the other profiles, for 
example plasma, using them as a guide to set my flags the way I need them.

Similarly with @system.  Negating the entire thing a package at a time 
and seeing what --depclean wants to clean, then adding as appropriate to 
a set listed in world_sets if it's /really/ needed, means I don't have to 
worry about package.providing openrc, for instance, because it's not 
necessary with systemd, once a single symlink is setup.  Similarly with 
ssh if it's only a stand-alone system you're admining.  And most of the 
@system virtuals can simply be dropped, as specific selections from those 
virtuals have already been added to some set listed in world_sets.

Of course it helps that my routine-use emerge aliases have --ask 
--verbose --oneshot.  (I don't configure those as emerge-defaults because 
I do for example want --pretend occasionally instead of --ask.)  But 
that's a lesson most gentooers should have learned within six months.

Anyway, USE="-*" hardly breaks the system here.  In fact, rather the 
opposite, it fixes what was previously a major headache of a workaround 
for a broken system every time my profile changed, because I was setting 
most USE flags I wanted but until then, not *ALL* of them, in part 
because I couldn't see what I had missed because the profile was setting 
it for me... until it didn't, thus creating the problem.

So for some people, especially those likely to have systems they're 
managing over a profile upgrade, USE="-*" is a guaranteed fix, not a 
guaranteed break. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Guidelines for IUSE defaults

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 692 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[James Le Cuirot]

On Thu, 2 Feb 2017 16:06:02 +0100
Kristian Fiskerstrand <k_f@gentoo.org> 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

[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] icedtea requiring X libs to build was -> Guidelines for IUSE defaults

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1645 bytes --]

On Thursday, February 2, 2017 10:36:51 AM EST 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.

In that specific case it cannot be avoided. Building is not the same as using. 
Even if you are not using aspects, they still need to be built. Even a 
headless server may do graphics manipulation, image, video, etc. Thus will 
require graphical type libraries to build those portions of Java.

Building something is not the same as using the result. You have the same 
issues with -bins, oracle, and icedtea. The difference is its pre-built. You 
would only run into issues if you tried to use a portion of Java that relied 
on system libraries not present. Thus those have use flags that will pull in 
additional libraries like javafx, etc.

People with this dream of building java from source do not really understand 
what all it takes. Building Java on a servers is not ideal as you will need X 
libraries, etc. To truly do it from source, you have to bootstrap back to 1.5, 
and build each version in succession. Or use a pre-build binary from a prior 
version to build current, icedted-7 (1.7) to build ~icedtea-3 (1.8).  
Versioning is another matter and topic.

Java is moving to a more modular build and deployment system. Starting with 
Java 9. Maybe in the future pieces can be built and a headless server version 
would not require X to build from source. Though given graphical library usage 
previously mentioned. Some parts may always bring in things you may not want 
on a server.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] icedtea requiring X libs to build was -> Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/02/2017 10:51 AM, William L. Thomson Jr. wrote:
> On Thursday, February 2, 2017 10:36:51 AM EST 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.
> 
> In that specific case it cannot be avoided.

Yes it can. I just have to waste my time unsetting the stupid USE flag
that's on for no reason =P

Re: [gentoo-dev] icedtea requiring X libs to build was -> Guidelines for IUSE defaults

[James Le Cuirot]

On Thu, 2 Feb 2017 10:53:08 -0500
Michael Orlitzky <mjo@gentoo.org> wrote:

> On 02/02/2017 10:51 AM, William L. Thomson Jr. wrote:
> > On Thursday, February 2, 2017 10:36:51 AM EST 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.  
> > 
> > In that specific case it cannot be avoided.  
> 
> Yes it can. I just have to waste my time unsetting the stupid USE flag
> that's on for no reason =P

Actually he's right. Java can obviously be used without GTK and that's
something we support but upstream hasn't taken the time to make it
possible to build without it. Apparently that isn't a trivial thing to
do.

In my earlier mail, I was only talking about runtime. If you really
want to avoid GTK on a server then you should stick to one of the -bin
packages. Hopefully Java 9 will improve on this.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] icedtea requiring X libs to build was -> Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/02/2017 11:09 AM, James Le Cuirot wrote:
> 
> Actually he's right. Java can obviously be used without GTK and that's
> something we support but upstream hasn't taken the time to make it
> possible to build without it. Apparently that isn't a trivial thing to
> do.
> 
> In my earlier mail, I was only talking about runtime. If you really
> want to avoid GTK on a server then you should stick to one of the -bin
> packages. Hopefully Java 9 will improve on this.
> 

Apologies: I was actually thinking of icedtea-bin... which ALSO pulls in
GTK due to IUSE defaults.

Re: [gentoo-dev] icedtea requiring X libs to build was -> Guidelines for IUSE defaults

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]

On Thursday, February 2, 2017 11:13:40 AM EST Michael Orlitzky wrote:
> On 02/02/2017 11:09 AM, James Le Cuirot wrote:
> > Actually he's right. Java can obviously be used without GTK and that's
> > something we support but upstream hasn't taken the time to make it
> > possible to build without it. Apparently that isn't a trivial thing to
> > do.
> > 
> > In my earlier mail, I was only talking about runtime. If you really
> > want to avoid GTK on a server then you should stick to one of the -bin
> > packages. Hopefully Java 9 will improve on this.
> 
> Apologies: I was actually thinking of icedtea-bin... which ALSO pulls in
> GTK due to IUSE defaults.

If you look at dev-java/icedtea ebuild you will see

# Gtk+ will move to COMMON_DEP in time; PR1982

I cannot find PR1982 referenced to link. But shows that it is needed and causes 
issues without being set.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] icedtea requiring X libs to build was -> Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/02/2017 11:18 AM, William L. Thomson Jr. wrote:
> 
> If you look at dev-java/icedtea ebuild you will see
> 
> # Gtk+ will move to COMMON_DEP in time; PR1982
> 
> I cannot find PR1982 referenced to link. But shows that it is needed and causes 
> issues without being set.
> 

I don't really want to fight about this. I have USE="-gtk" for
icedtea-bin, and run a few happy websites through Tomcat that haven't
yet noticed that GTK is missing.

But more importantly, icedtea-bin was just one example that I had in
mind. There are hundreds of others in the tree.

Re: [gentoo-dev] icedtea requiring X libs to build was -> Guidelines for IUSE defaults

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]

On Thursday, February 2, 2017 11:27:20 AM EST Michael Orlitzky wrote:
> On 02/02/2017 11:18 AM, William L. Thomson Jr. wrote:
> > If you look at dev-java/icedtea ebuild you will see
> > 
> > # Gtk+ will move to COMMON_DEP in time; PR1982
> > 
> > I cannot find PR1982 referenced to link. But shows that it is needed and
> > causes issues without being set.
> 
> I don't really want to fight about this. I have USE="-gtk" for
> icedtea-bin, and run a few happy websites through Tomcat that haven't
> yet noticed that GTK is missing.

Who is fighting? I am just explaining. Unless you go to use some graphical 
aspect of Java it will not matter. Same thing applies to oracle-jdk-bin if you 
do not have various USE flags set. It will not matter if you are not using Java 
code that relies on such. Nothing from java.awt.* for example. Previous link 
on headless shows stuff your likely not using, thus no issues.

GTK is not really necessary unless using swing/javafx, maybe some awt. The 
graphical aspects do not rely on GTK at its core. They do rely on various X 
libraries. When it comes to building that is another matter. GTK is needed to 
build a complete Java env. Just showing the comment since it was attempted to 
make GTK optional USE flag but has issues. I just cannot point specifically to 
the issues. Thus you can build and run without GTK, but eventually that will 
not be an option for reasons unknown in the PR comment.

> But more importantly, icedtea-bin was just one example that I had in
> mind. There are hundreds of others in the tree.

Sure, but some packages themselves go against a minimalist approach due to 
their own build requirements. You have to fight the package to make them 
minimal and I am not sure the fight is worth it at times.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] icedtea requiring X libs to build was -> Guidelines for IUSE defaults

[Michael Orlitzky]

On 02/02/2017 12:06 PM, William L. Thomson Jr. wrote:
> 
>> But more importantly, icedtea-bin was just one example that I had in
>> mind. There are hundreds of others in the tree.
> 
> Sure, but some packages themselves go against a minimalist approach due to 
> their own build requirements. You have to fight the package to make them 
> minimal and I am not sure the fight is worth it at times.
> 

We agree on that. If making GTK optional for your package is too much
trouble, then don't make it optional. The problem is only when the
maintainer does make it optional, and then defaults it on in every
profile using IUSE defaults. Most "give the user a typical system" USE
defaults belong in a desktop or server profile, not in the base.

Re: [gentoo-dev] icedtea requiring X libs to build was -> Guidelines for IUSE defaults

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1856 bytes --]

On Thursday, February 2, 2017 12:18:43 PM EST Michael Orlitzky wrote:
> On 02/02/2017 12:06 PM, William L. Thomson Jr. wrote:
> >> But more importantly, icedtea-bin was just one example that I had in
> >> mind. There are hundreds of others in the tree.
> > 
> > Sure, but some packages themselves go against a minimalist approach due to
> > their own build requirements. You have to fight the package to make them
> > minimal and I am not sure the fight is worth it at times.
> 
> We agree on that. If making GTK optional for your package is too much
> trouble, then don't make it optional.

Yes but that is part of the idea. Or I should say benefit of building Java from 
source. You could choose to make stuff optional that is not optional normally. 
But it is not trivial, and likely run into issues.

IMHO likely most if not all of the USE flags for any Java JDK/JRE should not 
exist. They are just reducing deps, with the idea that your not using code 
that needs that stuff. If you do, it will cause issues because you do not have 
those needed deps installed.

Really no way to please everyone. Either someone will want USE flags to reduce 
deps. Which could cause issues in the package. Which in turn have the USE flags 
enabled by default. Which upset others. There is no win for anyone.

> The problem is only when the
> maintainer does make it optional, and then defaults it on in every
> profile using IUSE defaults. Most "give the user a typical system" USE
> defaults belong in a desktop or server profile, not in the base.

Yes that is another matter. However somethings like Java cross over from 
server to desktop. It really just comes from trying to make it to modular. If 
there was no GTK/X/whatever USE flag, then it would not be an issue. But would 
still be bringing in the unwanted stuff into a server.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] icedtea requiring X libs to build was -> Guidelines for IUSE defaults

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 2362 bytes --]

On Thursday, February 2, 2017 10:53:08 AM EST Michael Orlitzky wrote:
> On 02/02/2017 10:51 AM, William L. Thomson Jr. wrote:
> > On Thursday, February 2, 2017 10:36:51 AM EST 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.
> > 
> > In that specific case it cannot be avoided.
> 
> Yes it can. I just have to waste my time unsetting the stupid USE flag
> that's on for no reason =P

If you understand headless you will understand the rest.
http://www.oracle.com/technetwork/articles/javase/headless-136834.html

You do not have to have GTK  USE flag or all of X, but you will be pulling in X 
libraries likely not present on the system to begin with. You may also 
experience various abnormal issues as this is not how Java is normally. 
Building it with different USE flags is pretty different than installing a pre-
built -bin with different USE flags.

On a headless server, a merge of icetea pulls in 48 packages, regardless if 
headless-awt USE is set or not. Just as an example. Same 48 packages to build, 
45 being new.

[ebuild  N     ] dev-java/icedtea-7.2.6.8:7::gentoo  USE="jbootstrap 
pax_kernel sunec -alsa (-cacao) -cjk -cups -debug -doc -examples -gtk -
headless-awt -infinality (-jamvm) -javascript -kerberos -libressl -nsplugin -
nss -pulseaudio -sctp (-selinux) -smartcard -source {-test} -webstart -zero" 
54,222 KiB

Total: 48 packages (45 new, 1 in new slot, 2 reinstalls), Size of downloads: 
309,943 KiB


[ebuild  N     ] dev-java/icedtea-7.2.6.8:7::gentoo  USE="headless-awt 
jbootstrap pax_kernel sunec -alsa (-cacao) -cjk -cups -debug -doc -examples -
gtk -infinality (-jamvm) -javascript -kerberos -libressl -nsplugin -nss -
pulseaudio -sctp (-selinux) -smartcard -source {-test} -webstart -zero"

Total: 48 packages (45 new, 1 in new slot, 2 reinstalls), Size of downloads: 
309,943 KiB

You can see -cups, but guess what, it is required and comes in regardless if 
USE flag is set or not. You will have to enable cups USE flag for other stuff.

# required by net-print/cups-filters-1.13.3::gentoo[postscript]
# required by net-print/cups-2.2.2-r1::gentoo
# required by dev-java/icedtea-7.2.6.8::gentoo
# required by icedtea (argument)
>=app-text/ghostscript-gpl-9.20-r1

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Thu, Feb 2, 2017 at 10:36 AM, Michael Orlitzky <mjo@gentoo.org> 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 10:52 AM, Rich Freeman wrote:
> On Thu, Feb 2, 2017 at 10:36 AM, Michael Orlitzky <mjo@gentoo.org> 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

[Rich Freeman]

On Thu, Feb 2, 2017 at 10:59 AM, Michael Orlitzky <mjo@gentoo.org> 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

[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 11:25 AM, Michael Orlitzky <mjo@gentoo.org> 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

[james]

On 02/02/2017 01:01 PM, Rich Freeman wrote:
> On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky <mjo@gentoo.org> 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 much of Iot is hacked and owned
by folks with nefarious intentions. Much of 'upstream' is growing
dumber by the day, and corporate manager and government interlopers
are just loving the cruft of 'upstream'.


Minimal is a close cousin to embedded, and now unikernels and aggressive 
HPC clusters are going that direction too in the name of performance, 
sane-management and reducing attack surfaces for the cloud or HPC 
cluster (not all, but many).


Surely a branch of the gentoo profiles tree, could rigorously be focused
on compatibility with upstream, but that inflexibility, if imposed
on everyone else, will only serve to further alienate gentoo-embedded 
and serve as a unnecessary wedge between some minimal, HPC and unikernel
types of gentoo builds.



> 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).


This is a whole other area of valid concern. Their was a GSoC project
last summer to work on organizing gentooish kernel builds, but that is a 
very big topic. Perhaps the profiles will have to be proposed but not
formalized until folks go out and do some kernel builds and testing 
associated with a proposed profile organization?


> 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.


Just formalize some new parts of the profile tree to not be required to 
be upstream compliant. Isn't that part of being a 'meta-distribution'?

In my future (and the future of many others) there will be minimalistic
builds on clusters where any number to constructs including 
compatibility  which will all be solved, at the framework level, not the 
base distro level, to the extent possible. Folks are now running a 
myriad of windows OS versions on linux (&clusters), so I have just read 
about a few days ago. So I'm proposing and working on gentoo 
heterogeneous cluster where one can partition part to be for systemd 
stuffage, part to be HPC, part to be extraordinarily secure, part to be 
aligned with a particularly commercial linux distro, and many other 
differing needs based frameworks.


The minimal (lowest level) should be clear of all of those distro 
encumbrances. CoreOS is taking this approach, as their bare metal 
bootstrapping occurs completely and well before systemd or any other
PID1 schema is invoked or becomes a defacto requirement.  Gentoo is all 
about freedom, right?


hth,
James

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Thu, Feb 2, 2017 at 3:35 PM, james <garftd@verizon.net> 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 04:05 PM, Rich Freeman wrote:
> On Thu, Feb 2, 2017 at 3:35 PM, james <garftd@verizon.net> 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 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.


I just do not see your 'either or scenario' as the only possibility. For 
example, in a recent gentoo-dev thread,  those profile owners (devs) 
were asked to step forward and state the  viability going forward of a 
profile review thread. If one of those devs wants one of those itemized 
profiles to continue to exist, is it going to be forcibly deleted?  (no)

So all I have to do is convince  (beg?) one dev to have a place in the 
profile tree that is not subservient to upstream dictates? Perhaps
another way forward for my work? (Glep-70?)


> Sure, you could do all that with a profile, but the problem is:
> 1.  Maintainers aren't going to necessarily invest in that profile.

Can I proxy-maintain a profile for minimized gentoo clusters?
Can I share a profile with another compatible (need) profile ?


> 2.  New users won't necessarily use that new profile.

That would be excellent. That's why there are many choices for profiles, 
right?


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

Non-sequitur....
user's will be on a handbook delineated profile choice; capable users
will be able to navigate handbook choices and other available profiles,
or seek (neddy?) guidance. The profile I'm talking about could
be logically under the old branch of 'experimental' if that survives 
too.  But would be best as close to the root of the profile tree, as 
possible.  The least amount of packages installed, is best, and located 
in a different branch than the default or whatever the new name is where 
a plethora of upstream issues exit. None of this would be a burden
to ebuilds, if they do not work, so be it, I can and will fix what I 
need from upstream. Every week, that list grows shorter and shorter, 
particularly for the minimal builds.


Hopefully I have justified and succinctly stated my vision, is 
accommodation not possible? 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.


hth,
James

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Thu, Feb 2, 2017 at 6:28 PM, james <garftd@verizon.net> 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

[David Seifert]

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 <mjo@gentoo.org>
> > 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 uncessary codes, for convenience and not care, but embedded,
> it does matter. That is why so much of Iot is hacked and owned
> by folks with nefarious intentions. Much of 'upstream' is growing
> dumber by the day, and corporate manager and government interlopers
> are just loving the cruft of 'upstream'.
> 
> 
> Minimal is a close cousin to embedded, and now unikernels and
> aggressive 
> HPC clusters are going that direction too in the name of
> performance, 
> sane-management and reducing attack surfaces for the cloud or HPC 
> cluster (not all, but many).
> 
> 
> Surely a branch of the gentoo profiles tree, could rigorously be
> focused
> on compatibility with upstream, but that inflexibility, if imposed
> on everyone else, will only serve to further alienate gentoo-
> embedded 
> and serve as a unnecessary wedge between some minimal, HPC and
> unikernel
> types of gentoo builds.
> 
> 
> 
> > 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).
> 
> 
> This is a whole other area of valid concern. Their was a GSoC project
> last summer to work on organizing gentooish kernel builds, but that
> is a 
> very big topic. Perhaps the profiles will have to be proposed but not
> formalized until folks go out and do some kernel builds and testing 
> associated with a proposed profile organization?
> 
> 
> > 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.
> 
> 
> Just formalize some new parts of the profile tree to not be required
> to 
> be upstream compliant. Isn't that part of being a 'meta-
> distribution'?
> 
> In my future (and the future of many others) there will be
> minimalistic
> builds on clusters where any number to constructs including 
> compatibility  which will all be solved, at the framework level, not
> the 
> base distro level, to the extent possible. Folks are now running a 
> myriad of windows OS versions on linux (&clusters), so I have just
> read 
> about a few days ago. So I'm proposing and working on gentoo 
> heterogeneous cluster where one can partition part to be for systemd 
> stuffage, part to be HPC, part to be extraordinarily secure, part to
> be 
> aligned with a particularly commercial linux distro, and many other 
> differing needs based frameworks.
> 
> 
> The minimal (lowest level) should be clear of all of those distro 
> encumbrances. CoreOS is taking this approach, as their bare metal 
> bootstrapping occurs completely and well before systemd or any other
> PID1 schema is invoked or becomes a defacto requirement.  Gentoo is
> all 
> about freedom, right?
> 
> 
> hth,
> James
> 

Dear James,
can you please stop totally drifting off topic and rambling about stuff
that is not relevant for the discussion at hand? We started at IUSE
defaults and you end with unikernels and HPC. Please stop the rambling.

hth,
David

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 <mjo@gentoo.org>
>>> 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 uncessary codes, for convenience and not care, but embedded,
>> it does matter. That is why so much of Iot is hacked and owned
>> by folks with nefarious intentions. Much of 'upstream' is growing
>> dumber by the day, and corporate manager and government interlopers
>> are just loving the cruft of 'upstream'.
>>
>>
>> Minimal is a close cousin to embedded, and now unikernels and
>> aggressive
>> HPC clusters are going that direction too in the name of
>> performance,
>> sane-management and reducing attack surfaces for the cloud or HPC
>> cluster (not all, but many).
>>
>>
>> Surely a branch of the gentoo profiles tree, could rigorously be
>> focused
>> on compatibility with upstream, but that inflexibility, if imposed
>> on everyone else, will only serve to further alienate gentoo-
>> embedded
>> and serve as a unnecessary wedge between some minimal, HPC and
>> unikernel
>> types of gentoo builds.
>>
>>
>>
>>> 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).
>>
>>
>> This is a whole other area of valid concern. Their was a GSoC project
>> last summer to work on organizing gentooish kernel builds, but that
>> is a
>> very big topic. Perhaps the profiles will have to be proposed but not
>> formalized until folks go out and do some kernel builds and testing
>> associated with a proposed profile organization?
>>
>>
>>> 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.
>>
>>
>> Just formalize some new parts of the profile tree to not be required
>> to
>> be upstream compliant. Isn't that part of being a 'meta-
>> distribution'?
>>
>> In my future (and the future of many others) there will be
>> minimalistic
>> builds on clusters where any number to constructs including
>> compatibility  which will all be solved, at the framework level, not
>> the
>> base distro level, to the extent possible. Folks are now running a
>> myriad of windows OS versions on linux (&clusters), so I have just
>> read
>> about a few days ago. So I'm proposing and working on gentoo
>> heterogeneous cluster where one can partition part to be for systemd
>> stuffage, part to be HPC, part to be extraordinarily secure, part to
>> be
>> aligned with a particularly commercial linux distro, and many other
>> differing needs based frameworks.
>>
>>
>> The minimal (lowest level) should be clear of all of those distro
>> encumbrances. CoreOS is taking this approach, as their bare metal
>> bootstrapping occurs completely and well before systemd or any other
>> PID1 schema is invoked or becomes a defacto requirement.  Gentoo is
>> all
>> about freedom, right?
>>
>>
>> hth,
>> James
>>
>
> Dear James,
> can you please stop totally drifting off topic and rambling about stuff
> that is not relevant for the discussion at hand? We started at IUSE
> defaults and you end with unikernels and HPC. Please stop the rambling.
>
> hth,
> David
>
>
>

Hello David.

The third post integrated 'profiles' into the discussion,included here
since you must have missed that::

"
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."
  co

Many other comments followed up and further discussed profiles. Only 
when I threw in my comments about the effects on profiles 'doth thy 
protest'?


Please give me a break, just ignore what you need to.


hth,
James

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 998 bytes --]

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.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 1558 bytes --]

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.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 12857 bytes --]

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 <mjo@gentoo.org> 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 flags is so users can deviate
from that, if they need or want to. Gentoo needs to be usable out of the
box; it can't be if we're dismantling the work we've put into figuring
out sane USE flags across the tree.

I'm not saying profiles are perfect, just that they make a decent
blueprint. With mixins likely coming to the tree, I'm excited to see
what's possible with them.
> 
> 
> 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*".

I do too, which is why I deal with it with my USE flags. It is, however,
upstream's software, and most of the time they're the most qualified to
determine what the default should be. Defaults aren't set in stone in
Gentoo; that's part of its beauty.

> 
> 
> 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.

Agreed.

> 
> 
> 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 much of Iot is hacked and owned
> by folks with nefarious intentions. Much of 'upstream' is growing
> dumber by the day, and corporate manager and government interlopers
> are just loving the cruft of 'upstream'.

I think that largely depends on your purpose for a given system. IoT
devices get cracked and abused mostly due to misconfiguration and a
failure to update when CVEs and whatnot are released. Being completely
Spartan may help against that, but as we all know... old code tends to
rot if not taken care of with at least backported patches.

Upstream is important because they supply 99% of the software we use. We
are just the distributors (hence "distribution"). We ideally shouldn't
have too strong of an opinion as maintainers; expose enough USE flags to
make a given package configurable, and apply '+' to upstream's default
stuff. I'd be surprised if a considerable number of packages on Gentoo
*weren't* that way.

Again, package.use (and maybe mixins) are the way to fix this.
> 
> 
> Minimal is a close cousin to embedded, and now unikernels and aggressive
> HPC clusters are going that direction too in the name of performance,
> sane-management and reducing attack surfaces for the cloud or HPC
> cluster (not all, but many).
> 
> 
> Surely a branch of the gentoo profiles tree, could rigorously be focused
> on compatibility with upstream, but that inflexibility, if imposed
> on everyone else, will only serve to further alienate gentoo-embedded
> and serve as a unnecessary wedge between some minimal, HPC and unikernel
> types of gentoo builds.
> 

Is there not an embedded profile? If that's where the beef is, perhaps
you should be talking to the embedded team rather than the greater
Gentoo dev community. They're likely better versed, and they *should* be
paying attention to gentoo-dev, as is expected from us. None of us works
in a vacuum, and we should be aware of what's happening with the whole
distribution, if only to see that there's activity somewhere.

A default Gentoo installation is not inflexible. It's merely a default
that can later be changed; even before your first call to 'emerge'.
> 
> 
>> 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).
> 
> 
> This is a whole other area of valid concern. Their was a GSoC project
> last summer to work on organizing gentooish kernel builds, but that is a
> very big topic. Perhaps the profiles will have to be proposed but not
> formalized until folks go out and do some kernel builds and testing
> associated with a proposed profile organization?

afaik building the kernel is completely outside of Portage's reach. It
merely installs the source files needed to build it. Everything else is
up to you and/or genkernel.

A special kernel fork designed for embedded sounds good, though. I'm
sure we've got something like that in the tree (or an overlay) somewhere.
> 
> 
>> 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.
> 
> 
> Just formalize some new parts of the profile tree to not be required to
> be upstream compliant. Isn't that part of being a 'meta-distribution'?

Don't we already do that? KDE, GNOME, and XFCE aren't "upstream"
compliant because there *isn't* a single, default upstream DE, so we
have profiles for that. If you or others would like to create or improve
existing profiles, then that's awesome and you should try to put
together some patches or a pull request so we can take a look.

> 
> In my future (and the future of many others) there will be minimalistic
> builds on clusters where any number to constructs including
> compatibility  which will all be solved, at the framework level, not the
> base distro level, to the extent possible. Folks are now running a
> myriad of windows OS versions on linux (&clusters), so I have just read
> about a few days ago. So I'm proposing and working on gentoo
> heterogeneous cluster where one can partition part to be for systemd
> stuffage, part to be HPC, part to be extraordinarily secure, part to be
> aligned with a particularly commercial linux distro, and many other
> differing needs based frameworks.
> 
> 
> The minimal (lowest level) should be clear of all of those distro
> encumbrances. CoreOS is taking this approach, as their bare metal
> bootstrapping occurs completely and well before systemd or any other
> PID1 schema is invoked or becomes a defacto requirement.  Gentoo is all
> about freedom, right?

If we need a new profile, then certainly those who are going to use it
should be best equipped to know what needs to be in it, right? This is a
great case for building what you need and then sharing it so everyone
can benefit. I don't do embedded (though I might tinker with it some
day), so I'm definitely not able to know what needs to be in such a
profile. We need people who actually work in that sort of stuff to do
the work, because if someone like me does it, then it may have too many
packages in it, or it won't account for X or Y use case that's super
common in embedded, etc.

Embedded is an itch, and non-embedded Gentoo people can't scratch it for
you because we aren't qualified. If you or others ever manage to make
that profile, please share it so others can benefit too. :)
> 
> 
> hth,
> James
> 

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[Gordon Pettey]

[-- Attachment #1: Type: text/plain, Size: 4087 bytes --]

On Thu, Feb 2, 2017 at 12:01 PM, Rich Freeman <rich0@gentoo.org> wrote:

> On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky <mjo@gentoo.org> 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.

[-- Attachment #2: Type: text/html, Size: 5344 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 7441 bytes --]

On Thu, 2 Feb 2017 18:01:54 -0600
Gordon Pettey <petteyg359@gmail.com> 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 <Profile X> x <Profile Y> 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
warnings when this happens.

If  A and B both have 2 profiles each, and depend on a third package C,
which has only 0 or 1 profiles (ie: "the only profile is a default profile"),
then as long as both A and B's profiles don't require changes in C, this should
be "legal"

C could enhance things later by adding an additional profile more in line with
A and B, changing the defaults to get closer to the ideals that profile defines.

And if A and B have profiles that necessitate C changing use flags, that should
cause repoman to error until a suitable profile is added to C that matches
 A and B.


Though yes, I understand I'm kinda thinking of a different way to implement
mixin profiles without necessitating a lot of global state to regulate it, so
mgorny probably hates me.

> 
> 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.

The only thing left that leaves me in a state of "ugh, this could be ugly"
is how application of multiple profile-use should be handled, if we go that way.

Naturally some packages A and B will have different profiles, and so you'll
want to pick 2 ... 

I guess this is where 'additive only' is helpful to an extent, but this
opens complexity city where additive unioning of multiple profiles
in a single package end up introducing a REQUIRED_USE mutual-exclusion,
thwarting the incentive for profiles entirely.

Unless ... 


IUSE_PROFILES="
   desktop & upstream  &   !gtk  & !gnome    -> ( qt )
   desktop & upstream  & (  gtk  |  gnome )  -> ( gtk qt )
   desktop & !upstream & (  gtk  |  gnome )  -> ( gtk )
" 

Ugh. No. This is all horrible. My head hurts just thinking about it.

Freedom of Choice is freedom to suffer in new and innovative ways.

1: https://bugs.gentoo.org/606260

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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 <mjo@gentoo.org> 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

[Rich Freeman]

On Thu, Feb 2, 2017 at 8:40 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
> On 02/02/2017 01:01 PM, Rich Freeman wrote:
>> On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky <mjo@gentoo.org> 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

[Patrick McLean]

On Thu, 2 Feb 2017 20:40:38 -0500
Michael Orlitzky <mjo@gentoo.org> wrote:

> On 02/02/2017 01:01 PM, Rich Freeman wrote:
> > On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky <mjo@gentoo.org>
> > 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

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 1691 bytes --]

On 02/02/17 10:14 PM, Patrick McLean wrote:
> On Thu, 2 Feb 2017 20:40:38 -0500
> Michael Orlitzky <mjo@gentoo.org> wrote:
> 
>> On 02/02/2017 01:01 PM, Rich Freeman wrote:
>>> On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky <mjo@gentoo.org>
>>> 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.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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]

[-- Attachment #1.1: Type: text/plain, Size: 1223 bytes --]

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?




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 1562 bytes --]

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.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[Patrick McLean]

On Fri, 3 Feb 2017 19:59:34 -0500
Ian Stakenvicius <axs@gentoo.org> 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

[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

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 2988 bytes --]

On Sat, 04 Feb 2017 12:44:38 -0500
"William L. Thomson Jr." <wlt-ml@o-sinc.com> 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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 5020 bytes --]

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." <wlt-ml@o-sinc.com> 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.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 3193 bytes --]

On Sat, 04 Feb 2017 16:05:50 -0500
"William L. Thomson Jr." <wlt-ml@o-sinc.com> 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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 2175 bytes --]

On 02/04/2017 01:05 PM, William L. Thomson Jr. wrote:
>[snip]
>> 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 can't speak for other maintainers but generally if there's an issue in
an ebuild I maintain, I try to figure out a) the specific problem, and
b) the simplest and most-effective solution. If an ebuild I maintain is
broken on arm64, for example, it's still my responsibility to figure out
how to get it working, assuming the software was written in a way to
allow for that build anyway. Since I don't run anything other than amd64
right now, I have to depend on others to find issues for other arches.
Generally I'll accept any change as long as it meets our ebuild
standards and doesn't exchange one problem for another.

One could argue "of course it benefits you", but I don't do it because
it benefits me. I do it because a) it fixes a problem I probably didn't
know about and b) it's how we make Gentoo better.

I don't have an opinion on profiles. I like the idea of them and respect
the work that goes into them. If maintainers need to make small changes
here or there so their packages work on specific profiles, I don't see
the problem. We do commit+push over typos; a profile is more important
than that, so naturally we should have little issue ironing out support
when the errant wrinkle comes up.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[Patrick McLean]

On Fri, 3 Feb 2017 08:43:50 -0500
Michael Orlitzky <mjo@gentoo.org> 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

[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

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 2189 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ben Kohler]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

On Thu, Feb 9, 2017 at 2:18 PM, Daniel Campbell <zlg@gentoo.org> 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

[-- Attachment #2: Type: text/html, Size: 1166 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 1543 bytes --]

On 02/09/2017 12:25 PM, Ben Kohler wrote:
> 
> 
> On Thu, Feb 9, 2017 at 2:18 PM, Daniel Campbell <zlg@gentoo.org
> <mailto:zlg@gentoo.org>> 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 <http://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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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]

[-- Attachment #1.1: Type: text/plain, Size: 1814 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[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

[James Le Cuirot]

On Thu, 2 Feb 2017 10:36:51 -0500
Michael Orlitzky <mjo@gentoo.org> 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

[Dirkjan Ochtman]

On Thu, Feb 2, 2017 at 4:36 PM, Michael Orlitzky <mjo@gentoo.org> 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

[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

[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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Sam Jorna]

[-- Attachment #1: Type: text/plain, Size: 2635 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 1006 bytes --]

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]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 1006 bytes --]

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]

[-- Attachment #1: Type: text/plain, Size: 944 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 1006 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Thu, Feb 2, 2017 at 9:06 PM, Michael Orlitzky <mjo@gentoo.org> 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: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

[Patrick McLean]

On Thu, 2 Feb 2017 21:06:33 -0500
Michael Orlitzky <mjo@gentoo.org> 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

[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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

>>>>> 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)

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

On Tue, 7 Feb 2017 08:52:06 +0100
Ulrich Mueller <ulm@gentoo.org> 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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 944 bytes --]

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 <ulm@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 724 bytes --]

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.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]

>>>>> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Tue, Feb 7, 2017 at 10:14 AM, Ian Stakenvicius <axs@gentoo.org> 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

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 1685 bytes --]

On 07/02/17 12:00 PM, Rich Freeman wrote:
> On Tue, Feb 7, 2017 at 10:14 AM, Ian Stakenvicius <axs@gentoo.org> 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.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[Sam Jorna]

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

On Tue, Feb 07, 2017 at 12:00:51PM -0500, Rich Freeman wrote:
> On Tue, Feb 7, 2017 at 10:14 AM, Ian Stakenvicius <axs@gentoo.org> 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 1006 bytes --]

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Tue, Feb 7, 2017 at 8:24 PM, Sam Jorna <wraeth@gentoo.org> 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 <axs@gentoo.org> 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]

[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]

On Tue, Feb 07, 2017 at 09:11:20PM -0500, Rich Freeman wrote:
> On Tue, Feb 7, 2017 at 8:24 PM, Sam Jorna <wraeth@gentoo.org> 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 <axs@gentoo.org> 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 1006 bytes --]