Re: [gentoo-dev] Guidelines for IUSE defaults

[Kent Fredric]

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