| View previous topic :: View next topic |
| Like the idea? |
| yes |
|
41% |
[ 5 ] |
| no |
|
58% |
[ 7 ] |
|
| Total Votes : 12 |
|
| Author |
Message |
avx
Advocate
Joined: 21 Jun 2004
Posts: 2152
|
 Posted: Wed Apr 21, 2010 12:46 pm Post subject: [proposal] /etc/packages.d |
 |
|
One thing I love about Gentoo, is that I can build every package the way I like/want/need it to be, with the help of USE, per-package CFLAGS, etc. What I don't like is, that I need a whole lot of files and directories to achieve that, which I find often cumbersome to manage - besides, I think /etc/portage is a bad name since it can imho be misunderstood.
What I propose is the OPTION (! haters out  ) to have all this stuff in a more unified and better to manage way.
1. create the dir /etc/packages.d, so /etc/portage is really only for direct portage-behaviour configfiles(bashrc, postsync, etc)
2. either have one big file to store everything (packages.conf - or the like) or be able to use a tree like /etc/packages.d/maj-min/pkg
3. unify - in terms of "everything in on place" - the data, f.e. something like this
| /etc/packages.d/packages wrote: | | maj-min/pkg U(this -that) C(icc) F(-O3 -msse4) L(--as-needed) K(~amd64) S(de_DE en_US) V(!>=x.y) D(nodoc buildpkg) T(*.doc AUTHORS) |
or | /etc/packages.d/maj-min/pkg wrote: | | U(this -that) C(icc) F(-O3 -msse4) L(--as-needed) K(~amd64) S(de_DE en_US) V(!>=x.y) D(nodoc buildpkg) T(*.doc AUTHORS) |
U = USE-flags
C = compiler
F = compiler-flags
L = linker-flags
K = keyword
S = languages to build
V = version masks/unmask
D = "do" aka FEATURES from make.conf
T = "trash" aka INSTALL_MASK from make.conf
Non-existing or empty ?() should be threated with the default settings.
Good/bad idea? Overlooked something? Praises/hate? Comments? |
|
| Back to top |
|
 |
Sadako
Advocate
Joined: 05 Aug 2004
Posts: 3792
Location: sleeping in the bathtub
|
| Posted: Wed Apr 21, 2010 1:09 pm Post subject: |
|
|
Three thoughts on this;
| avx wrote: | I think /etc/portage is a bad name since it can imho be misunderstood.
1. create the dir /etc/packages.d, so /etc/portage is really only for direct portage-behaviour configfiles(bashrc, postsync, etc) |
Completely disagree, everything you're talking about is related to package management, and is inherintly linked to the portage tree, so should all be under the one package management directory.
I'd even go so far as to say that the /etc/make.* files/symlinks should be under /etc/portage too, as nothing else really makes use of them...
| avx wrote: | | /etc/packages.d/packages wrote: | | maj-min/pkg U(this -that) C(icc) F(-O3 -msse4) L(--as-needed) K(~amd64) S(de_DE en_US) V(!>=x.y) D(nodoc buildpkg) T(*.doc AUTHORS) |
or | /etc/packages.d/maj-min/pkg wrote: | | U(this -that) C(icc) F(-O3 -msse4) L(--as-needed) K(~amd64) S(de_DE en_US) V(!>=x.y) D(nodoc buildpkg) T(*.doc AUTHORS) |
|
Fugly!
Finally, although it's not perfect, something like the above already exists in /etc/portage/env, you can override most variables such as CFLAGS on a per-package basis through that (not to mention the very useful EXTRA_ECONF), the only problems with that (IMO) are that not every variable can be overridden this way, and it doesn't inherit the variables already set in make.conf (although you could just source make.conf in each file).
edit: although, I do kinda agree that all the different portage configuration options are kind of a mess, as they were all added to portage as it eveolved rather than planned from the beginning, but sorting that out would not be an easy task and I don't expect to see anyone tackling it anytime soon.
I'd be much more interested in one detailed and comprehensive source on documentation on all the portage/package configuration options, most people have no idea about /etc/portage/env, as it doesn't seem to be documented anywhere (I can't even remember how I stumbled upon it myself), and I have no idea how to patch a package through portage without copying the ebuild to an overlay and adding an epatch statement to it, another poorly documented but potentially very useful feature...
_________________
"You have to invite me in" |
|
| Back to top |
|
|
avx
Advocate
Joined: 21 Jun 2004
Posts: 2152
|
| Posted: Wed Apr 21, 2010 1:15 pm Post subject: |
|
|
You hater Well, I just chose this format since it's quite easy to parse and at least it's not as fugly as XML 
| Quote: | | Finally, although it's not perfect, something like the above already exists in /etc/portage/env |
Didn't know about that, gotta see if I find some docs. Edit, well there goes your edit. No docs is bad :/
Would be nice, if you're using the env, if you could give me a sample, thx. |
|
| Back to top |
|
|
Sadako
Advocate
Joined: 05 Aug 2004
Posts: 3792
Location: sleeping in the bathtub
|
| Posted: Wed Apr 21, 2010 1:28 pm Post subject: |
|
|
| avx wrote: | | I just chose this format since it's quite easy to parse and at least it's not as fugly as XML |
I hear that...
| Quote: | | Would be nice, if you're using the env, if you could give me a sample, thx. |
Okay, take media-gfx/gimp for example, you create the /etc/portage/env directory, than the directory corresponding to the package category within that (ie media-gfx), then add your variables to a file with the package name, eg; | /etc/portage/env/media-gfx/gimp: | CFLAGS="-O3 -march=k8-sse3 -fforce-addr -pipe"
CXXFLAGS="${CFLAGS}"
EXTRA_ECONF="--enable-gimp-remote" |
There is talk of a new official gentoo wiki, which could be the perfect place to document all of this in depth, the only problem is finding someone who understands it all well enough to do it right...
_________________
"You have to invite me in" |
|
| Back to top |
|
|
avx
Advocate
Joined: 21 Jun 2004
Posts: 2152
|
| Posted: Wed Apr 21, 2010 1:34 pm Post subject: |
|
|
This works oot-box with portage >=2.2? What exactly is EXTRA_ECONF good for or what does it do in your example? (Edit, lemme guess, directly pass something to the ./configure-process/-script?)
Sorry to ask you all this :p (what about the old rule, "no software without proper documentation", damnit  ) |
|
| Back to top |
|
|
Sadako
Advocate
Joined: 05 Aug 2004
Posts: 3792
Location: sleeping in the bathtub
|
| Posted: Wed Apr 21, 2010 1:41 pm Post subject: |
|
|
Whatever you have in EXTRA_ECONF is added to the arguments passed to ./configure in the package, in the example I gave the gimp used to have a "gimp-remote" utility built by default, which would allow you to open an image in an already running instance of the gimp from the command line.
Upstream changed to disabling this by default as of 2.6 (and AFAICT no one here missed it apart from me...), so this let's me enable it without copying gimp to an overlay, and it works with each version bump just fine.
I have no idea if it works with packages which use other build systems though, such as cmake.
Here's another example for you; | /etc/portage/env/x11-terms/rxvt-unicode: | | EXTRA_ECONF="--disable-unicode3 --disable-rxvt-scroll --disable-next-scroll --disable-xterm-scroll --disable-xim --disable-keepscrolling --disable-slipwheeling " |
urxvt is really one of those packages you're better off configuring yourself, and EXTRA_ECONF gives me an easy way to do that via portage.
_________________
"You have to invite me in" |
|
| Back to top |
|
|
avx
Advocate
Joined: 21 Jun 2004
Posts: 2152
|
| Posted: Wed Apr 21, 2010 1:48 pm Post subject: |
|
|
| Wow, did some googling on "extra_econf" and according to this bug, it's been there since 2003? WTF? https://bugs.gentoo.org/35986 |
|
| Back to top |
|
|
Etal
Veteran
Joined: 15 Jul 2005
Posts: 1931
|
| Posted: Wed Apr 21, 2010 2:11 pm Post subject: |
|
|
| I wish there was something like /etc/portage/env/ but for sets, so that I could, for example, add 'FEATURES=splitdebug' for all KDE packages and 'CFLAGS="-O99 --omg-optimized"' for another set of packages without creating a few hundred separate files. |
|
| Back to top |
|
|
Sadako
Advocate
Joined: 05 Aug 2004
Posts: 3792
Location: sleeping in the bathtub
|
| Posted: Wed Apr 21, 2010 2:25 pm Post subject: |
|
|
| AM088 wrote: | | I wish there was something like /etc/portage/env/ but for sets, so that I could, for example, add 'FEATURES=splitdebug' for all KDE packages and 'CFLAGS="-O99 --omg-optimized"' for another set of packages without creating a few hundred separate files. |
That's an idea I'd get behind, even though I don't actually make use of the sets functionality yet.
In fact, it'd probably be the thing to make me start using sets...
Currently I have a load of symlinks under /etc/portage/env pointing to a couple of files for changing the -O level in CFLAGS...
_________________
"You have to invite me in" |
|
| Back to top |
|
|
avx
Advocate
Joined: 21 Jun 2004
Posts: 2152
|
| Posted: Wed Apr 21, 2010 2:43 pm Post subject: |
|
|
Do we somewhere have a list of "safe flags for ricing"? I.e. we have the normal safe-flags, which are known to work for about any package, but of course don't give optimal performance. Therefor a list stating "$package can safely handle $ricerflags without problems without errors" would be nice. Someone has that, knows of any or would be interested to help with such a thingy?
Edit, the said sets-feature would be nice to have, indeed. |
|
| Back to top |
|
|
Sadako
Advocate
Joined: 05 Aug 2004
Posts: 3792
Location: sleeping in the bathtub
|
| Posted: Wed Apr 21, 2010 2:54 pm Post subject: |
|
|
| avx wrote: | | Do we somewhere have a list of "safe flags for ricing"? I.e. we have the normal safe-flags, which are known to work for about any package, but of course don't give optimal performance. Therefor a list stating "$package can safely handle $ricerflags without problems without errors" would be nice. Someone has that, knows of any or would be interested to help with such a thingy? |
tbh, I'm not sure how useful that would be, even with -O2 and -O3, the "fastest" or "best" is entirely package-dependent.
What I'd love to see is an effort to determine the best flags per package, starting with the -O level, but also seeing what other flags could be of benefit, for example there are surely some packages which yield better performance with -O2, but could see some improvements with some but not all the extra flags included in -O3 added...
It wouldn't have to be for every package, I believe the number of packages in portage where a noticable performance difference could be observed is actually fairly small, if we started out on the common libraries first, like anything related to (de)compression/(de)coding for one, or rendering such as the various UI toolkits...
There was a little discussion on this around here somewhere before...
_________________
"You have to invite me in" |
|
| Back to top |
|
|
avx
Advocate
Joined: 21 Jun 2004
Posts: 2152
|
| Posted: Wed Apr 21, 2010 2:57 pm Post subject: |
|
|
@Hopeless, that's exactly what I meant 
For example, I know that mplayer, x264, firefox, xz-utils, ... can benefit from more aggressive-flags. So, recompile the packages with different flags, test for performance/errors/build-failures and then post the gathered information somewhere - ricing for the best stable I'd call it^^ |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
