From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 69D4B138CAE for ; Mon, 4 May 2015 04:36:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 40DD1E0893; Mon, 4 May 2015 04:36:37 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 397AAE0867 for ; Mon, 4 May 2015 04:36:36 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Yp87N-0005ZV-GV for gentoo-dev@lists.gentoo.org; Mon, 04 May 2015 06:36:33 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 May 2015 06:36:33 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 May 2015 06:36:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: RFC: c++14 global USE flag Date: Mon, 4 May 2015 04:36:28 +0000 (UTC) Message-ID: References: <20150424194217.0176adc0@googlemail.com> <553A91F6.7080505@gentoo.org> <553BA02E.7000805@gentoo.org> <20150425152317.20001.qmail@stuge.se> <553FE89B.2000903@gentoo.org> <5540C01C.7090202@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT e424b98) X-Archives-Salt: d6f0ae8f-c9a8-4b0b-9419-8b0ef0baaabf X-Archives-Hash: e17df7e7d97129f70107a82473db7f02 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