On Thu, 2 Feb 2017 18:01:54 -0600 Gordon Pettey <petteyg...@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
pgpMAfQnlC5iS.pgp
Description: OpenPGP digital signature
