How to Improve emerge/make.conf?

[Nathanael]

Fist of all, I think this is the best place to the post but if I'm wrong, or if this has been posted before, please just tell me.
Second sorry for my bad English but is not my mother tonge.

Since I began with gentoo I enjoyed to much to be able to take control of every part of the system, but (Yes there is always a but! ) I found that some parts of the process are unnecessarily "complicated".
So I want to know if out there is more people like me, and how they think things could be improved.
Example:

I think is a lost of time have to change the USE variables every time I re-build some program if in my make.conf are not the ones I wanted to use with it.
I partially solved this using ufed a lot of times, and putting the different sets commented, but still I have to uncomment the lines I need for the program at the moment I emerge it.

So I think it would be a good idea to change it a bit, letting it to be able to identify one package and the set of USE flags that the user wants to use exclusively with it.
Someting like:
----------------------------------------------------------------------------------------------------
default USE="mmx 3dnow memlimit gtk2 cups"

kadebase USE="cups"
gnome USE="-alsa"
...
and so on..
---------------------------------------------------------------------------------------------------
Still letting the user to control what he/she wants and also releasing it to do an unnecessary extra work.
_________________
"La única pregunta estúpida es la no formulada"

[puggy]

Well. What I do is always start with a emerge -pv package. e.g.

[Nathanael]

Yes, I already know all that, thanks (You know, the portage User Guide and all the other Docs, and of course the Forums!! )
And normally is a good way to me, and is what I do in my home computer.
But in diferent fields like in the work network (more than 20 computers with gentoo installed, from one P90 to a PowerPC G4 through a Pentium4).
Where you have the same programs in diferent machines with the same config to ensure compatibility and equality of features. And at the same time you have to provide the best yield, is a bit of stress to have to change the make.conf every time you upgrade a program or rebuild one because you detected some incompatibility issue, or just because you forgot one.
_________________
"La única pregunta estúpida es la no formulada"

[dol-sen]

I like the idea! To slightly modify it, maybe a -r (--remember) option could be added to emerge to remember the any options desired for a specific package. That way during the emerge it would save the settings for mod_php and use those settings for any other updates as in

[dol-sen]

The -r option would also fit very easily into a database based version of emerge, since it would already have sql ability, addings comand line settings would be easy.

See the portage database thread.
_________________
Brian
Porthole, the Portage GUI frontend irc@freenode: #gentoo-guis, #porthole, Blog
layman, gentoolkit, CoreBuilder, esearch...

[RedBeard0531]

Portage already (sorta) does this.

[KiTaSuMbA]

[dol-sen]

The cat method while useful is not what Nathanael needed, nor what I suggested.

I think that the -r option would be best to just remember the commandline options used to call emerge. That way it would not matter which mak.conf setting was overriden for the emerge, whether it is :
ACCEPT_KEYWORDS="~arch", USE=, FEATURES=, CFLAGS=, etc.

/etc/make.conf would be the primary user settings for emerges, & the -r option would remember any commandline overrides used to call emerge. Any desired changes for that one particular package emerge would be saved. Only the last one used would be saved, so that when trying to emerge a difficult compile the last one used re-writes over the previous one. When you finally get it right for "something" no further work is needed and no override versions need to be tracked or (forgotten) to be deleted.

Cancelling a previous -r save would be as easy as

[KiTaSuMbA]

dol-sen:
The idea of including all env options of a specific emerge is more complete than just the USE flags although a lot more harder.
But even by that way, ovveriding ability should still exist since it's more often than not that a version upgrade comes with a new set of flags and sometimes deprecates older ones. (need an example? how about that -cjk on the xfree?). If -r works in an "absolute coherency" way, you just forced your user to set all the flags again by hand because of a single one little option he wants to add.
_________________
Need to flame people LIVE on IRC? Join #gentoo-otw on freenode!

[Nathanael]

hummm..!
I see the diferent points of view, and I like both.
but maybe a diferent aproach would be useful too.
For example:
If you install one package for the first time the KISS emerge -r option would be fine, but
if is an update then doing emerge -r, first would do an emerge -pv, and then compare te flags, and if they are not the same, then keep only the coincident ones, erase the deprecated, and ask if you want the new ones.
So there would be no annoyances if it is not necessary.

PD:Excuse my spell please but im in a hurry...
_________________
"La única pregunta estúpida es la no formulada"

[KiTaSuMbA]

[dol-sen]

What I was saying about the -r function is only to record the commandline, checking use flags and conflicts should already be done in emerge. Checking use flag conflicts and such should be done separately in emerge. After all, if you don't check on use flag changes now you may still have to re-emerge packages when you find something missing. The -r function should only make things more automatic for unique package needs, not global funtionality. I do agree with portage checking for and informing of confilcts, use flag changes between updates. That should be a different module within portage.

The -r function would be the last step in the make.globals => make.conf chain. The result would be

make.globals = default options setings
make.conf = user settings that override make.global settings
-r commandline option = records commandline overrides to the above for the package


KISS
_________________
Brian
Porthole, the Portage GUI frontend irc@freenode: #gentoo-guis, #porthole, Blog
layman, gentoolkit, CoreBuilder, esearch...