i see that now after that emerge the /etc/make.conf is not seen anymore.
it has been removed or merged with the portage/make.conf.
i cold not find a make.conf in /etc_________________reach out a little bit more to catch it (DON'T BELIEVE the advocate part under my user name)

This is just a reaction to a bug (I forgot the number) which suggests that portage should warn if the old locations are found so that user do not get confused if one gets overridden by the other. I doubt that portage will stop to support the old locations.

can someone please pay attention to this?
For me it is really a bug because MAN page https://dev.gentoo.org/~zmedico/portage/doc/man/make.conf.5.html do not state that files are in conflict, they could both exist together and this is actually what I want to achieve as well. System-based /etc/make.conf while local admin can tune it via /etc/portage/make.conf

Unfortunately last update is more than one year old. Is there a way how to escalate this?

just reply with it with some more infomation (not just a *bump*)_________________The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king

I'm afraid it's my bug, like many of my bugs, i just lost hope and drop the issue. You cannot "battle" any dev in bugs.gentoo.org ; that's something i've learned the hard way.
But if you feel luckier or less bore than me, good luck.

I think if you want to reopen the bug you should at least mention which specific problem you want to solve: I cannot see that Zac's valid question about the reason was answered in that bug report. However:

IMHO, this is a bug in the manpage: It should probably be recommended to drop the old location.
Obviously, the reason why the old location is still supported and documented is to avoid forcing users to a transition which might cause unexpected breakage for them; you can (and should) not expect more from it than a compatibility cludge:
The manpage is not clear at all what happens if both files exist: Does one information override the other? can variables from one file be used in the other? etc... So any behaviour in the corner case of both files existing is "valid".

Quote:

and this is actually what I want to achieve as well. System-based /etc/make.conf while local admin can tune it via /etc/portage/make.conf

Meanwhile, /etc/portage/make.conf can be a directory. Thus, there are much better ways to achieve what you want: You can make in this directoy symlinks to one (or several) "your whole computer zoo"-defaults, to one (or several) more system-specific overrides, as well as one (or several) local overrides (which all in turn can be directories as well). I recommend to give the symlinks names like "20-global-defaults" "50-my-graphics-hardware" etc (i.e., starting with numbers) so that you can be sure about the order in which the files are read (so that you can use "global" variables as shortcuts in more specific files, etc.).
I use this since years and find it much more flexible and clearer than to rely on undocumented behaviour of an "old" location overriding a "new" location of a config file or vice versa: You as the admin can explicitly determine the order (by the names) and can fine-tune which files override which other files (e.g. you can even have several local and global files overriding each other partly which might be useful in a very complex system zoo).
BTW: This new approach also plays much better with ufed, since you can have USE-flags in their own separate file which is then modified by ufed.

The manpage is not clear at all what happens if both files exist: Does one information override the other? can variables from one file be used in the other? etc... So any behaviour in the corner case of both files existing is "valid".

Why would you want to put a broken symlink there? Why not create an empty file, a link to /dev/null, or remove the link if you do not want to put anything in it? Alternatively, you could rename the symlink into a hidden file (starting with .) - then portage would ignore it.

Edit: Out of interest, I just tested and have put a dead symlink in /etc/portage/make.conf: portage silently ignores it, so you can use it in the way you want it. (Although I still do not understand the reason.)

Meanwhile, /etc/portage/make.conf can be a directory. Thus, there are much better ways to achieve what you want: You can make in this directoy symlinks to one (or several) "your whole computer zoo"-defaults, to one (or several) more system-specific overrides, as well as one (or several) local overrides (which all in turn can be directories as well). I recommend to give the symlinks names like "20-global-defaults" "50-my-graphics-hardware" etc (i.e., starting with numbers) so that you can be sure about the order in which the files are read (so that you can use "global" variables as shortcuts in more specific files, etc.).

Sure, at the end this will be better as it is already widely used in all Linux systems (sysctl.d, logrotate.d, ...) but it will take much more time to achieve that. In our case I just need to remove approximately two lines of code._________________

if you take a look at first example, i just show you the link is broken because i unmount the mount point.

if my server has any problem, the mount point would be dead and the symlink broken, in that case, emerge will still works fine with all settings set by /etc/make.conf on each hosts.

while when using the same trick with source, portage is broken and output an error message.

So yes, there's a real and big difference between using the two forms : when both have their symlink working, no difference, but when symlink are broken one form lead to portage working (and better! knowing the server is down) while the second form lead to portage is not working.

Maybe there is a misunderstanding: This is already supported since years (from all tools which I use - including portage and eix); you just have to execute a few "mkdir" and "mv" commands once to use it now

iif my server has any problem, the mount point would be dead and the symlink broken

I would be glad to get an error message in such a case instead of a possibly wrong configuration.
If you are in an emergency situation, you can just create an empty file or remove/rename the symlink temporarily.

I would be glad to get an error message in such a case instead of a possibly wrong configuration.

Well i just don't, it's not portage works to tell me that, and it doesn't mean i'm in an emergency case anyway (i could myself just took it down on purpose).

But this gave me ability to use stuff like that:
FEATURES="-distcc" and CFLAGS="-march=native" or set MAKEOPTS="-j2" in /etc/make.conf
and FEATURES="distcc" in /etc/portage/make.conf with some MAKEOPTS="-j10"...
(that's not really about the server problem, as i just disable it so no host try to use any others hosts as helper if server is down and my network "may" be in trouble).

But i don't think i need to justify anything really, one form works, the other doesn't, it should be enough to anyone to consider such a change a problem.
And the problem is not that we might loose that ability to use both make.conf the problem is that using it you get a stupid message that is not informative to anyone as it doesn't tell user it's deprecated to use them both, just that it found two make.conf ; and this always even you are fully aware of it.
And not only by emerge but also by tools that use emerge like revdep-rebuild that for whatever reason output this like 3 or 5 times.

I would be glad to get an error message in such a case instead of a possibly wrong configuration.

Well i just don't, it's not portage works to tell me that

IMHO it is, if a config file cannot be read.
Anyhow, your problem can be solved with the appropriate /etc/portage/make.conf directory now (since dangling symlinks are ignored).

The ability to use some sort of conditionals in /etc/portage/make.conf would be nice, though: As almost always in config-files, it would be preferrable to have the full power of a programming language like a shell instead of just a limited possibility to set some variables. We had this discussion already in one of the systemd threads...

Anyhow, your problem can be solved with the appropriate /etc/portage/make.conf directory now (since dangling symlinks are ignored).

OK, I'll take your word for it, as I'm not following all the ins and outs atm.

Quote:

The ability to use some sort of conditionals in /etc/portage/make.conf would be nice, though: As almost always in config-files, it would be preferrable to have the full power of a programming language like a shell instead of just a limited possibility to set some variables. We had this discussion already in one of the systemd threads...

It seems like what krinn had working before (base /etc/portage and overrides in /etc) allows him to do everything you might have wanted with a full-blown interpreter.

More recently, profiles in overlays can have bashrc selected in the same way as package.env, ie by conf filename.

It seems like what krinn had working before (base /etc/portage and overrides in /etc) allows him to do everything you might have wanted with a full-blown interpreter.

It allows him to do exactly one "test": Whether nfs is on or off (or however he mounts). He might want to do a different test: based on hostname, network status, connected machines, ... a lot of uses might be thinkable.
Without a shell, he has to rely on a compatibility cludge which just works undocumented "by accident" just in his case, and he is lost, once this cludge is removed or works differently. This is exactly what I would prefer to not rely on in my config-files.

Quote:

profiles in overlays can have bashrc selected in the same way as package.env

I do not see the relation with this discussion: You also cannot select based on conditionals; and bashrc is full bash code, i.e. you can do all sort of tests anywayy, but unfortunately, it comes "too late" for many settings from make.conf.
It is not too late for CFLAGS/LDFLAGS 'though; I do use it (with some tricky tests) for setting CFLAGS, but then for this, one bashrc is enough, and I do not need a further selection mechanism, since I do the selection in bash.