From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: RFC: c++14 global USE flag
Date: Mon, 4 May 2015 04:36:28 +0000 (UTC) [thread overview]
Message-ID: <pan$7dfeb$b583b83$50e7fefe$fc14b52@cox.net> (raw)
In-Reply-To: CAGbUWSL+zt9a67H3x_QbPstxZbXJ9c7pocXyGmw7Sox1QWxwvg@mail.gmail.com
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@cox.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
next prev parent reply other threads:[~2015-05-04 4:36 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-24 18:12 [gentoo-dev] RFC: c++14 global USE flag Maxim Koltsov
2015-04-24 18:42 ` Ciaran McCreesh
2015-04-24 18:56 ` Ian Stakenvicius
2015-04-24 19:11 ` Maxim Koltsov
2015-04-24 19:28 ` Georg Rudoy
2015-04-25 14:09 ` Anthony G. Basile
2015-04-25 15:23 ` Peter Stuge
2015-04-25 15:57 ` [gentoo-dev] " Duncan
2015-04-26 16:41 ` Diego Elio Pettenò
2015-04-27 3:21 ` Duncan
2015-04-28 20:07 ` Anthony G. Basile
2015-04-28 21:52 ` Mike Gilbert
2015-04-29 11:27 ` Anthony G. Basile
2015-05-02 21:11 ` Maxim Koltsov
2015-05-02 21:17 ` Kent Fredric
2015-05-02 22:18 ` Georg Rudoy
2015-05-02 22:30 ` Kent Fredric
2015-05-03 10:19 ` Maxim Koltsov
2015-05-03 10:51 ` Duncan
2015-05-03 14:13 ` Georg Rudoy
2015-05-04 4:36 ` Duncan [this message]
2015-05-03 14:08 ` Georg Rudoy
2015-05-03 14:04 ` Georg Rudoy
2015-05-03 19:07 ` Kent Fredric
2015-05-04 3:29 ` Duncan
2015-04-25 15:47 ` [gentoo-dev] " Matthias Maier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$7dfeb$b583b83$50e7fefe$fc14b52@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox