[gentoo-dev] Re: RFC: c++14 global USE flag
Georg Rudoy posted on Sun, 03 May 2015 17:13:49 +0300 as excerpted: > 2015-05-03 13:51 GMT+03:00 Duncan <1i5t5.dun...@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 seman
[gentoo-dev] Re: RFC: c++14 global USE flag
Georg Rudoy posted on Sun, 03 May 2015 17:04:54 +0300 as excerpted: > Speaking of llvm, media-libs/mesa has "llvm" use flag. Why should user > care if it's llvm or whatever? The local use-description tells the store there: "Enamble LLVM backend for Gallium3D" In this case, LLVM is the feature, and it is billed as such by upstream. Gallium3D can optionally use LLVM to compile shading-language programs to run on the programmable shaders. An alternative USE flag name would be shading-vm, or similar, but because upstream actually "sells" the feature as an LLVM shading language backend, LLVM really is as much the feature as would be shading-vm or shading-compiler or some such, except because it /does/ pull in an LLVM that people might not otherwise need on their machine, the llvm flag is actually more descriptive, since it says what it pulls in as a dep, as well. Of course, if there were multiple choices, then it could either be a generic shading-compiler flag, with flags for each compiler as well, or it could be setup as a USE_EXPAND list, sl_llvm, sl_gcc, sl_amd, sl_intel... -- 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
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-05-03 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2015-05-03 23:59 UTC. Removals: dev-java/jna-posix 2015-04-28 20:44:42 chewi games-emulation/tuxnes 2015-04-29 21:52:11 mr_bones_ dev-games/libgrapple2015-04-29 22:01:18 mr_bones_ games-strategy/xconq2015-04-29 22:03:09 mr_bones_ games-simulation/stoned-bin 2015-04-29 22:04:35 mr_bones_ games-sports/racer-bin 2015-04-29 22:06:52 mr_bones_ games-strategy/savage-bin 2015-04-29 22:08:25 mr_bones_ games-puzzle/drod-bin 2015-04-29 22:09:10 mr_bones_ games-strategy/dominions2-demo 2015-04-29 22:10:30 mr_bones_ games-server/bf1942-desertcombat2015-04-29 22:38:17 mr_bones_ games-rpg/rain-slick2015-04-29 22:39:34 mr_bones_ games-fps/ut2004-damnation 2015-04-29 22:40:54 mr_bones_ games-fps/ut2004-da22015-04-29 22:41:45 mr_bones_ games-fps/quake3-brainworks 2015-04-29 22:42:45 mr_bones_ games-fps/quake1-ctf2015-04-29 22:43:28 mr_bones_ games-fps/enemy-territory-fortress 2015-04-29 22:44:45 mr_bones_ games-fps/doom3-phantasm2015-04-29 22:45:59 mr_bones_ games-action/descent1-maps 2015-04-29 22:47:31 mr_bones_ dev-perl/extutils-depends 2015-05-01 12:55:51 dilfridge app-laptop/gtkpbbuttons 2015-05-02 16:00:51 dilfridge app-laptop/gkrellm-pmu 2015-05-02 16:01:54 dilfridge sys-firmware/iwl7265-ucode 2015-05-03 05:42:59 prometheanfire dev-perl/class-returnvalue 2015-05-03 10:57:44 dilfridge dev-perl/Apache-AuthTicket 2015-05-03 23:15:37 zlogene dev-perl/Eidetic2015-05-03 23:16:44 zlogene app-admin/rackview 2015-05-03 23:19:04 zlogene Additions: dev-python/ddt 2015-04-28 20:18:36 prometheanfire app-crypt/keybase 2015-04-29 22:56:26 nicolasbock dev-db/lmdb++ 2015-04-30 16:47:51 nicolasbock dev-python/oslo-concurrency 2015-04-30 16:48:59 prometheanfire dev-python/oslo-policy 2015-04-30 17:05:35 prometheanfire dev-python/semantic_version 2015-04-30 18:58:56 prometheanfire dev-libs/liberasurecode 2015-04-30 19:34:46 prometheanfire dev-python/PyECLib 2015-04-30 19:39:33 prometheanfire dev-python/mypy 2015-05-01 01:28:15 alunduil dev-perl/ExtUtils-Depends 2015-05-01 11:43:29 dilfridge dev-python/livereload 2015-05-02 15:18:04 alunduil dev-perl/Class-ReturnValue 2015-05-03 10:46:11 dilfridge x11-misc/grub2-theme-preview2015-05-03 12:28:31 sping -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-java/jna-posix,removed,chewi,2015-04-28 20:44:42 games-emulation/tuxnes,removed,mr_bones_,2015-04-29 21:52:11 dev-games/libgrapple,removed,mr_bones_,2015-04-29 22:01:18 games-strategy/xconq,removed,mr_bones_,2015-04-29 22:03:09 games-simulation/stoned-bin,removed,mr_bones_,2015-04-29 22:04:35 games-sports/racer-bin,removed,mr_bones_,2015-04-29 22:06:52 games-strategy/savage-bin,removed,mr_bones_,2015-04-29 22:08:25 games-puzzle/drod-bin,removed,mr_bones_,2015-04-29 22:09:10 games-strategy/dominions2-demo,removed,mr_bones_,2015-04-29 22:10:30 games-server/bf1942-desertcombat,removed,mr_bones_,2015-04-29 22:38:17 games-rpg/rain-slick,removed,mr_bones_,2015-04-29 22:39:34 games-fps/ut2004-damnation,removed,mr_bones_,2015-04-29 22:40:54 games-fps/ut2004-da2,removed,mr_bones_,2015-04-29 22:41:45 games-fps/quake3-brainworks,removed,mr_bones_,2015-04-29 22:42:45 games-fps/quake1-ctf,removed,mr_bones_,2015-04-29 22:43:28 games-fps/enemy-territory-fortress,removed,mr_bones_,2015-04-29 22:44:45 games-fps/doom3-phantasm,removed,mr_bones_,2015-04-29 22:45:59 games-action/descent1-maps,removed,mr_bones_,2015-04-29 22:47:31 dev-perl/extutils-depends,removed,dilfridge,2015-05-01 12:55:51 app-laptop/gtkpbbuttons,removed,dilfridge,2015-05-02 16:00:51 app-laptop/gkrellm-pmu,removed,dilfridge,2015-05-02 16:01:54 sys-firmware/iwl7265-ucode,removed,prometheanfire,2015-05-03 05:42:59 dev-perl/class-returnvalue,removed,dilfridge,2015-05-03 10:57:44 dev-perl/Apache-AuthTicket,removed,zlogene,2015-05-03 23:15:37 dev-perl/Eidetic,removed,zlogene,2015-05-03 23:16:44 app-admin/rackview,removed,zlogene,2015-05-03 23:19:04 Added Packages: dev-python/ddt,added,prometheanfire,2015-04-28 20:18:36 app-crypt/keybase,added,nicolasbock,2015-04-29 22:56:26 dev-db/lmdb++,added,nicola
Re: [gentoo-dev] Re: RFC: c++14 global USE flag
On 4 May 2015 at 02:04, Georg Rudoy <0xd34df...@gmail.com> wrote: > Why should the user care if python is supported? What does python support > per se offer to the user? I would argue that what's important are the > features exposed via Python stuff (unless the user theyself is expected to > write some Python code, of course). > > By support "for" python, I mean "This flag exposes a new feature to userspace". For instance, it may install python modules that a user may desire to consume in the course of their programming. Thus, they are not likely to want that flag on, unless they are doing exactly that. Or a dependant may require those modules to be available, and may depend on that package with the flag enabled to access those libraries. Thus, the "feature" that the flag exposes is "Support for people or code who explicitly need something python related in using it". Same logic applies for C++14, IMHO. > The same logic here would be: - People are developing their own code for leechcraft that needs leechcraft to be compiled differently for them to do that, and that flag changes how leechcraft is compiled so that they can do that - Some dependent is in the above situation, and wishes to be able to force leechcraft to be compiled so that it may work. Simply put: "Compiled using C++14" is not a "feature" unless somebody somewhere explicitly needs C++14 compilation. > >> What does it matter to a user that its in C++14 ? It doesn't. >> > And end user is more concerned with "what does this do for me". >> >> If a useflag doesn't tell me what it does for me, then what impetus is >> there for me to toggle it? >> > > The consequences do matter, like pulling and building llvm/clang, if not > present already. Toggle it if you're ready to deal with the consequences > (having clang in your system, particularly). > > Speaking of llvm, media-libs/mesa has "llvm" use flag. Why should user > care if it's llvm or whatever? > > > For instance, Seamonkey doesn't have a USE=perl flag. Nor should it have >> one. >> > > Nice example with USE=perl, thanks! git has that, for instance. Without > that, `git add -i` won't work, but I still have USE=perl, not > USE=add_interactive and possibly a bunch of other features depending on > Perl that would pull it when enabled. > Right, its not a black/white thing, and I would argue that flag on git is poorly named. But the general pattern is its recommended to express useflags to users in terms of "things I can see will be useful to me", thus, if you can make a more purpose-specific flag, it is wise to do so. Its not that doing it that way is "wrong" per say. Just a sub-optimal choice that requires more thinking. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Re: RFC: c++14 global USE flag
2015-05-03 13:51 GMT+03:00 Duncan <1i5t5.dun...@cox.net>: > What about a somewhat more generic flag such as newcode? Like the bindist > or minimal flags, this could be global, but with local descriptions very > strongly recommended. Similarly, like minimal, setting it globally would > be strongly discouraged. > > In this case, the newcode local description would be something like: > > C++14 related: gcc doesn't support yet, requires clang > > ... with an appropriate use-conditional dep. > > The newcode flag would however be generic enough that it could be reused > for C++17, etc, as well, and could obviously be phased out for any > particular package once its specific newcode dependencies are met in > stable -- in this case, when a supporting gcc stabilizes. > 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? > 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). > 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. -- Georg Rudoy
Re: [gentoo-dev] Re: RFC: c++14 global USE flag
2015-05-03 13:19 GMT+03:00 Maxim Koltsov : > Well, I can see your point. But I don't see any reasonable alternative --- > this functionality can't be generalized by any name, except "c++14" --- > that's only thing in common. > Yes, exactly. > Moreover, this is (I hope) a _temporal_ solution, until there's a gcc with > needed level of support. > I have increasing concerns about that. The relevant bugreport ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60177 ) is more than a year old, and still no feedback on it from gcc guys. Moreover, this bug is hardly related to C++11/14 — it's pure 03. I could live with some kludges in C++11, but they became incompatible with some of C++14. -- Georg Rudoy
Re: [gentoo-dev] Re: RFC: c++14 global USE flag
2015-05-03 1:30 GMT+03:00 Kent Fredric : > and python very often *is* saying "Support for python" ( not in, but _for_ > ) > Why should the user care if python is supported? What does python support per se offer to the user? I would argue that what's important are the features exposed via Python stuff (unless the user theyself is expected to write some Python code, of course). Same logic applies for C++14, IMHO. > What does it matter to a user that its in C++14 ? It doesn't. > And end user is more concerned with "what does this do for me". > > If a useflag doesn't tell me what it does for me, then what impetus is > there for me to toggle it? > The consequences do matter, like pulling and building llvm/clang, if not present already. Toggle it if you're ready to deal with the consequences (having clang in your system, particularly). Speaking of llvm, media-libs/mesa has "llvm" use flag. Why should user care if it's llvm or whatever? > For instance, Seamonkey doesn't have a USE=perl flag. Nor should it have > one. > Nice example with USE=perl, thanks! git has that, for instance. Without that, `git add -i` won't work, but I still have USE=perl, not USE=add_interactive and possibly a bunch of other features depending on Perl that would pull it when enabled. -- Georg Rudoy
[gentoo-dev] Re: RFC: c++14 global USE flag
Maxim Koltsov posted on Sun, 03 May 2015 13:19:18 +0300 as excerpted: > this functionality can't be generalized by any name, except "c++14" --- > that's only thing in common. Moreover, this is (I hope) a _temporal_ > solution, until there's a gcc with needed level of support. And of > course we can put a message about this flag in eclass and/or on > LeechCraft site. What about a somewhat more generic flag such as newcode? Like the bindist or minimal flags, this could be global, but with local descriptions very strongly recommended. Similarly, like minimal, setting it globally would be strongly discouraged. In this case, the newcode local description would be something like: C++14 related: gcc doesn't support yet, requires clang ... with an appropriate use-conditional dep. The newcode flag would however be generic enough that it could be reused for C++17, etc, as well, and could obviously be phased out for any particular package once its specific newcode dependencies are met in stable -- in this case, when a supporting gcc stabilizes. 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, 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. 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. -- 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
Re: [gentoo-dev] Re: RFC: c++14 global USE flag
2015-05-03 1:30 GMT+03:00 Kent Fredric : > > On 3 May 2015 at 10:18, Georg Rudoy <0xd34df...@gmail.com> wrote: > >> We have "idn" or "gnutls" or "python" etc USE flags after all, not >> "support_international_names_in_blah" or >> "allow_secure_news_fetching_in_foo" or "build_scripting_support_for_baz". >> >> Or I just didn't get you here, sorry me in this case :) >> > > > The difference is semantics. > > "idn" *is* saying "Support for international names" ( not in, but _for_ ) > > and python very often *is* saying "Support for python" ( not in, but _for_ > ) > > That's "for", not "by". For support *by* python, an explicit python > use-flag is not entirely necessary. > > Just like you presently don't have ( and we don't have ) a "USE=c" flag > just to make sure you have a C compiler. > > What does it matter to a user that its in C++14 ? It doesn't. > > And end user is more concerned with "what does this do for me". > > If for instance a specific user visible tool became magically available > with "USE=C++14", and that was the only tool that became visible as a > result, that would, for example, be really silly. > > If a useflag doesn't tell me what it does for me, then what impetus is > there for me to toggle it? > > For instance, Seamonkey doesn't have a USE=perl flag. Nor should it have > one. > > It does however have a USE=crypt flag, which utilizes perl as part of its > work. ( And its only a compile time dependency also ). > > But you seem to want USE=perl # turn on crypt features > > Which is inherently backwards. > > There is still places where that makes a degree of sense, but in cases > like "give new user facing features features" an ambiguous "C++" toggle is > not going to be communicating intent in an appropriate manner. > > Well, I can see your point. But I don't see any reasonable alternative --- this functionality can't be generalized by any name, except "c++14" --- that's only thing in common. Moreover, this is (I hope) a _temporal_ solution, until there's a gcc with needed level of support. And of course we can put a message about this flag in eclass and/or on LeechCraft site.
[gentoo-dev] Last rites: dev-ruby/fssm
# Hans de Graaff (3 May 2015) # dev-ruby/fssm is deprecated by its author and nothing # in the tree depends on it anymore. Use dev-ruby/listen # as an alternative. Masked for removal in 30 days. dev-ruby/fssm signature.asc Description: This is a digitally signed message part
