Bug 92657 – Proposal to extend functionality of /etc/make.conf and /etc/portage/package.*

• Product: Portage Development
• Status: VERIFIED LATER

[Description Oleg Kostyuk 2005-05-14 18:07:51 UTC]

I want to maintain a few servers with same /etc/make.conf and /etc/portage/package.* (sharing via NFS), but for several packages I need to use different USE flags on different boxes.
My proposition - provide /etc/make.conf.local and /etc/portage/package.*.local to override "global" settings.

In that way I can maintain one "global" /etc/make.conf for all boxes, for example wit such setting:
	USE="-X -java ...."
and share it via NFS, but on some box(es) i can write:
	USE="java"
into /etc/make.conf.local, and got USE flags "-X java" on this box.

I propose this because most of boxes - it's productions servers and I want to have it as similar as it's possible (to simplify maintance), but for some applications I need to use unusual USE flags or KEYWORDS masking.
Also I think that this will be helpful not only to me ;)

Reproducible: Always
Steps to Reproduce:

[Comment 1 SpanKY 2005-05-14 18:23:26 UTC]

you could just maintain your own profile as a subprofile

figure out what your current profile is (readlink /etc/make.profile) and then remove /etc/make.profile and make that into a dir

in /etc/make.profile/parent, tell it to inherit the old profile, and then put all your global settings into /etc/make.profile/

for more info see `man portage`

[Comment 2 Marius Mauch (RETIRED) 2005-05-15 11:09:45 UTC]

echo "source /etc/make.conf.local >> /etc/make.conf"

should work too. Will have slightly different semantics though.
In general do what Mike said as you're really using your own profile already.

Still won't help with package.{keywords,use}.

[Comment 3 Oleg Kostyuk 2005-05-20 06:21:43 UTC]

Thanks alto for your answers, it's was very useful.

Creating my own profile - is (mainly) all that I need.
But there is one question, for which I can't find answer.
The question is:
  What I should use in my own profile to select individual USE-flags for some 
individual packages? In other words, where or who is analog 
of /etc/portage/package.use in my own profile?

I try to find out answer by myself, but still unsuccessfully :(
And last comment from Marius give up my hope :((

Can anyone help me with this?
Do you have any plans to include such support into cascading profiles?

[Comment 4 SpanKY 2005-05-20 06:26:12 UTC]

there is no profile support for per-package USE flags

but you can just put the flags into USE in make.defaults

[Comment 5 Oleg Kostyuk 2005-05-20 06:28:31 UTC]

I think that this not help me.

For example, I want to USE="ncurses -slang" for all system, execpt Midcnight 
Commander ("-ncurses slang") - and want to define this in my own profile.

Can I do this in some way?

[Comment 6 Alec Warner (RETIRED) 2005-05-20 07:07:00 UTC]

(In reply to comment #5)
> I think that this not help me.
> 
> For example, I want to USE="ncurses -slang" for all system, execpt Midcnight 
> Commander ("-ncurses slang") - and want to define this in my own profile.
> 
> Can I do this in some way?

There is no profile support for per-package use flags, set them in /etc/portage/
package.use.

[Comment 7 Oleg Kostyuk 2005-05-21 05:37:00 UTC]

> There is no profile support for per-package use flags

Do you have any plans to include such support into cascading profiles?

[Comment 8 Jason Stubbs (RETIRED) 2005-05-21 05:52:53 UTC]

I think Nakano's proposal way back when of unifying what can be done 
with /etc/portage and with /etc/portage/profile is a good idea. There's no 
need to enforce via portage that package.keywords and the like not be used in 
profiles. In some cases, such as this, there are valid uses. 

[Comment 9 Jason Stubbs (RETIRED) 2005-07-28 07:25:38 UTC]

Putting a hold on feature requests for portage as they are drowning out the 
bugs. Most of these features should be available in the next major version of 
portage. But for the time being, they are just drowning out the major bugs and 
delaying the next version's progress. 
 
Any bugs that contain patches and any bugs for etc-update or dispatch-conf can 
be reopened. Sorry, I'm just not good enough with bugzilla. ;) 

[Comment 10 Marius Mauch (RETIRED) 2007-01-12 06:04:23 UTC]

This is fixed by now when using package.* directories.