Re: [gentoo-dev] Guidelines for IUSE defaults

[Kent Fredric]

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