Re: [gentoo-dev] New basic systemd profile
On Fri, 1 May 2015 11:28:52 -0400 Mike Gilbert wrote: > Due to popular demand, I have added a basic systemd profile for amd64: what about we start telling people /etc/make.profile can be a dir and that you can fill the 'parent' file in there just as well as you ln -s it ? Alexis.
Re: [gentoo-dev] New basic systemd profile
On Sat, May 2, 2015 at 4:20 AM, Alexis Ballier wrote: > On Fri, 1 May 2015 11:28:52 -0400 > Mike Gilbert wrote: > >> Due to popular demand, I have added a basic systemd profile for amd64: > > what about we start telling people /etc/make.profile can be a dir > and that you can fill the 'parent' file in there just as well as you ln > -s it ? That is the whole mix-in concept. In order to make that work we'd really need to work towards it. You can't inherit profiles in arbitrary order. If you want something like mix-ins you really need to split profiles up into certain classes and define rules about which ones are used for what. Then they won't be stepping on each other's toes. But yes, you could probably get away with it in many cases without any special support from the distro. -- Rich
Re: [gentoo-dev] New basic systemd profile
On Sat, 2 May 2015 05:53:57 -0400 Rich Freeman wrote: > On Sat, May 2, 2015 at 4:20 AM, Alexis Ballier > wrote: > > On Fri, 1 May 2015 11:28:52 -0400 > > Mike Gilbert wrote: > > > >> Due to popular demand, I have added a basic systemd profile for > >> amd64: > > > > what about we start telling people /etc/make.profile can be a dir > > and that you can fill the 'parent' file in there just as well as > > you ln -s it ? > > That is the whole mix-in concept. In order to make that work we'd > really need to work towards it. You can't inherit profiles in > arbitrary order. If you want something like mix-ins you really need > to split profiles up into certain classes and define rules about which > ones are used for what. Then they won't be stepping on each other's > toes. Rules that make that work are simple, but instead, we seem to be heading towards '# of arches * # of DEs * # of init systems * # of gentoo releases * # of ABIs * # of libcs' profiles. Most of them being just about a 'parent' file, and thus, I hope, following the good practices :) Alexis.
Re: [gentoo-dev] New basic systemd profile
On Sat, May 2, 2015 at 11:26 AM, Alexis Ballier wrote: > On Sat, 2 May 2015 05:53:57 -0400 > Rich Freeman wrote: > >> On Sat, May 2, 2015 at 4:20 AM, Alexis Ballier >> wrote: >> > On Fri, 1 May 2015 11:28:52 -0400 >> > Mike Gilbert wrote: >> > >> >> Due to popular demand, I have added a basic systemd profile for >> >> amd64: >> > >> > what about we start telling people /etc/make.profile can be a dir >> > and that you can fill the 'parent' file in there just as well as >> > you ln -s it ? >> >> That is the whole mix-in concept. In order to make that work we'd >> really need to work towards it. You can't inherit profiles in >> arbitrary order. If you want something like mix-ins you really need >> to split profiles up into certain classes and define rules about which >> ones are used for what. Then they won't be stepping on each other's >> toes. > > > Rules that make that work are simple, but instead, we seem to be heading > towards '# of arches * # of DEs * # of init systems * # of gentoo > releases * # of ABIs * # of libcs' profiles. Most of them being just > about a 'parent' file, and thus, I hope, following the good practices :) > Someone needs to do the work of writing the rules down. Also, repoman probably needs to be adjusted so that we actually test some useful subset of the possible combinations. There's no such support today.
Re: [gentoo-dev] Re: RFC: c++14 global USE flag
2015-04-29 14:27 GMT+03:00 Anthony G. Basile : > On 04/28/15 17:52, Mike Gilbert wrote: > >> On Tue, Apr 28, 2015 at 4:07 PM, Anthony G. Basile >> wrote: >> >>> On 04/26/15 23:21, Duncan wrote: >>> Diego Elio Pettenò posted on Sun, 26 Apr 2015 17:41:04 +0100 as excerpted: On 25 April 2015 at 16:57, Duncan <1i5t5.dun...@cox.net> wrote: > > Of course, one thing that could make the process faster would be if >> C++ >> based packages were marked some way. >> > > revdep-rebuild --soname 'libstdc\+\+.so.*' > > should do the trick. Stuff that does not link the library (statically > linked or using libsupc++) should not really matter. > Thanks. Obvious in hindsight. =:^) just saw this. This works unless you have two versions of gcc >>> installed. >>> The c++11 abi emitted by gcc-4.7 and 4.8 are different and since you link >>> against the latest version (see the ordering of directories in >>> /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf), building with the >>> earlier >>> gcc can cause breakage. We may not want to support such a situation but >>> I'd >>> like to. >>> >> As I understand it, a given version of gcc links objects against its >> own version of libstdc++, but the "latest" version of libstdc++ is >> loaded by ld.so at runtime. >> >> Maybe that's what you meant, but I wanted to clarify that. And if I am >> wrong on that, please correct me. ^_^ >> >> > Yes. So you could, for example, fix this by setting the correct rpath at > link time so the correct library gets loaded at runtime. I fear this discussion is going in a slightly wrong direction. I'm not going to make any global Gentoo changes, I just need to add support for C++14 mode in a bunch of packages I maintain, and for that, I need to decide on a place to store USE descriptions. If I won't get good options, I'll just go and add this description to every of ~70 metadata's. Please consider the patch I'm going to apply to our eclass: https://bpaste.net/show/39ec6f4760f4 This is intended as an experimental feature, not as a globally supported configuration for every package in Gentoo. This is needed because already now LeechCraft has some functionality that is implemented in C++14 and won't be available otherwise. Please give your opinion on where to put this USE desc, that's all I want :) > -- > Anthony G. Basile, Ph.D. > Gentoo Linux Developer [Hardened] > E-Mail: bluen...@gentoo.org > GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA > GnuPG ID : F52D4BBA > >
Re: [gentoo-dev] Re: RFC: c++14 global USE flag
On 3 May 2015 at 09:11, Maxim Koltsov wrote: > LeechCraft has some functionality that is implemented in C++14 and won't > be available otherwise. > Can you clarify the nature of that functionality? Shouldn't the USE flag be thus in terms of what that functionality is, not in terms of the dependency required to provide it? -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Re: RFC: c++14 global USE flag
2015-05-03 0:17 GMT+03:00 Kent Fredric : > > On 3 May 2015 at 09:11, Maxim Koltsov wrote: > >> LeechCraft has some functionality that is implemented in C++14 and won't >> be available otherwise. >> > > Can you clarify the nature of that functionality? > The Tox support module and email client module (the latter isn't in tree yet, but a good example anyway) both rely on relaxed constexpr from C++14. In some of the newer code I rely on automatic return type deduction and generic lambdas, for example, or some changes in STL. Thus, it's safer to say that basically all new modules that are written (and would be written) since ~January 2015 would require C++14 as a baseline language. Moreover, C++14 allows writing more efficient code (without extra levels of indirection induced by std::function required if one is to specify the return type of a function returning a lambda, for example) in some places. > Shouldn't the USE flag be thus in terms of what that functionality is, not > in terms of the dependency required to provide it? > Since the most general criteria for the functionality is "whether C++14 compiler is available", "c++14" or something like that seems the best fit for the USE flag name. 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 :) -- Georg Rudoy
Re: [gentoo-dev] Re: RFC: c++14 global USE flag
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. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
