[gentoo-dev] Re: RFC: c++14 global USE flag

[Duncan]

Georg Rudoy posted on Sun, 03 May 2015 17:13:49 +0300 as excerpted:

> 2015-05-03 13:51 GMT+03:00 Duncan <1i5t5.duncan@×××.net>:
>
>> What about a somewhat more generic flag such as newcode?

> Nice idea, thanks! There are a couple of corner cases though.
>
>> newcode would even be generic enough to be used for say qt6 when the
>> time comes, if it turns out to be stuck in the qt overlay for quite
>> some time, as was qt5, for the longest time,
>
>
> What if a package would support (optional) builds with C++17-related
> features and (optional) builds with say Qt6, and these could be toggled
> independently? Does that imply having something like newcode_cpp17 and
> newcode_qt4 on per-package basis?

Hmm... indeed.  That case would lend itself to a USE_EXPAND, with newcode 
the name of the use-expand var, and individual values for this var of 
qt6, cpp17, etc.

I hadn't thought of that until you mentioned it, but it's the logical 
extension.

>> and the good bit is, generic meaning,
>> that USE=newcode requires a dep that's still generally problematic or
>> might be considered excessive to get, for optional functionality that
>> may or may not be considered worth it, should be pretty obvious.
>>
>>
> Does that imply that merely pulling clang for builds is not a
> newcode-concern then, and, back to the original topic, in case of
> leechcraft C++14 can be enabled unconditionally, again with
> unconditional pulling of clang?
>
> That's probably a way to go, but feels like not Gentoo-way enough (just
> removing an option).

I think that depends on the package and package maintainer, as much as 
anything.  The real question for the maintainer, then, becomes one of "If 
it comes down to it, would I rather that a potential user reject the 
package entirely due to this dependency they consider unacceptable, in 
ordered to save the hassle of maintaining the optional dependency code, 
or would I rather give them the choice and have to maintain that 
additional optional dependency code?"

Leachcraft is a very nice little niche, but it's a niche, that already 
both isn't particularly likely to be discovered, and if discovered, may 
well not be of interest.  Making the clang dep optional sounds like it'll 
be significantly more work, the cost on the one side, while the cost on 
the other is potentially limiting the already niche interest leachcraft 
to an even smaller niche, and giving up on those people who were thinking 
about installing it just to try out, but see that extra dep and decide 
it's not worth their hassle.

And of course it works the other way too.  There may be people who 
already know and use leachcraft, but can barely justify it already, who 
might decide that additional dependency is simply one dependency too far.

I found here, and I expect many experienced gentooers who have also used 
binary distros will agree, for packages you use all the time, the build-
cost difference between a binary distro and a from-source distro like 
gentoo is trivial, the use of the package far outweighs it anyway.  But 
what about that package you only use once in awhile?  I guess CD/DVD 
burning software might be a good example for many.  Maybe they use it 
once or twice a year, maybe every two years.  Yeah, it's useful, once in 
awhile, and on a binary distro, no problem, just install it.  But on a 
from source distro like gentoo, once you find yourself repeatedly 
upgrading it between uses, so you're not even using the package once 
before it's upgraded again, at some point you ask yourself why you even 
keep it installed.  If you decide you want to burn a DVD, you can merge 
it then, do the burn, and unmerge, without it ever hitting the world 
file, and with your next depclean removing it if you forget.

And once you get to that point, additional exclusive deps start adding up 
pretty quickly, and before you know it you're looking for an alternative 
that doesn't pull in all those extra deps, so it's just the quick build/
merge/burn/unmerge that fits the once every couple years use-case.

So again, maintainer viewpoint, for something already niche, is it worth 
the extra work to avoid it being even /more/ niche due to the uncommon 
mandatory dep, or is it a question of of it's niche already, and is 
hardly worth the work already, so just do what's simplest and the people 
that want it will be willing to jump thru the hoops and those that can't 
be bothered, aren't worth the extra work to worry about?

That's a question only the maintainer can answer, particularly for niche 
packages that chances are would end up without a maintainer and 
eventually tree-cleaned, if the current maintainer quits.

(For more mainstream packages or package-groups, say kde, with an 
extremely active overlay and a whole crew of folks both devs and advanced 
user volunteers helping out, it's a bit of a different story.  Tho the 
general principle still applies, because in practice it's the only way 
that works.  Refer to the kde4 semantic-desktop experience for example -- 
semantic-desktop was removed as an option and made required in the 
overlay and ~arch, because none of the maintainers were sufficiently 
interested in doing the extra work to support the option.  Fortunately 
one of the kde devs decided they wanted that feature option, I believe 
before it was removed from stable, so it survived at least thru kde4 (I'm 
actually not sure what semantic-desktop status is on kde5/frameworks, as 
kwin5 doesn't seem to like my radeon kernel/mesa native graphics and goes 
into a crash/respawn loop every time I try it, so I'm still on kde4, for 
now).  But as a pre-release and even kde-live-9999 package user, I was 
having to maintain the semantic-desktop opt-out version patches for my 
own overlay, for a time, and as it hit ~arch and almost hit stable, I and 
other users came very close to creating a user-maintained kde-semantic-
free overlay, using the the user-maintained kde-sunset overlay as our 
precedent.)

>> Making that meaning even more obvious would be the fact that the flag
>> would likely be packageuse-masked for many users for much of the the
>> time.  That could for instance allow packages using it in-tree, before
>> the dep it pulls in is itself in-tree, while still making it possible
>> to unmask, for users who either already have the required overlay
>> active, or who don't have it active ATM, but are willing to activate it
>> to get the features it toggles.
>>
>>
> Depending on the answer to the previous question, if all the deps are
> in-tree, then there is no need in masking the useflag. It could be
> unmasked on the per-package basis again, I guess? Then there is a
> question of the default (globally unmasked and per-package masks vs
> globally masked and per-package unmasks), but that's a relatively minor
> one.

Well, technically, in-tree and stable.  But I was abbreviating that to in-
tree, so you can too, as long as the technical detail is understood.

And yes, that's specifically what per-package use-masks are all about, to 
allow packages to stabilize before all their optional deps are 
stabilized, by per-package use-masking the flags that pull in those deps.  
(Note that I'm deliberately blurring the detail here, too, as I read the 
discussion about per-package masks, how to unmask them when needed, etc, 
when it occurred, but I've never had to actually unmask from that here, 
and I'm user-side so haven't had to worry about the dev side either, and 
thus haven't had to actually crystallize the detail in practice here, and 
thus read but haven't retained it.  But I know about it and can look up 
the details if I need them, which is enough...)

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