| Summary: | portage(5) man page: document make.conf and such may be directories | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | nobody <noreply> |
| Component: | Core - Configuration | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Keywords: | InVCS |
| Priority: | Normal | ||
| Version: | 2.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 452176 | ||
| Bug Blocks: | 484436 | ||
|
Description
nobody
2013-04-08 21:06:51 UTC
The plan is to deprecate the old paths eventually (see bug 452176). Presence of two make.conf files typically indicates misconfiguration. If you want to have two separate you have two options: 1) use the 'source' command 2) use directory recursion support (see bug #463266) Ah thanks for the bug link: - Right now the message is still useless, it don't tell me it's deprecated - The feature is still in the man page of portage As soon as feature is deprecated (i hope far far far later) i will have to find another solve. But until then, that message is useless, i didn't saw it until now, but revdep-rebuild also spam it, and much more than just 3 times. Could we have an option to disable it, you know for the ones that know what they are doing using a deprecated feature that might disappear one day, but like it this way. (and maybe put a more explicit message for other that don't know what they are doing) I don't have any example to gave, but this kind of change may affect users using script that parse emerge output too. Could this issue be solve with a news instead (lol ok sorry, i didn't check if any news was made already, so if it's already done, i agree it's a good idea then) my /etc/make.conf hold CFLAGS and /etc/portage/make.conf is a symlink to an exported make.conf from my server that all my hosts shared (so if the server is offline, all hosts can still fallback to /etc/make.conf) A neat way to propagate global changes to all my hosts while keeping specifics CFLAGS (not only that) for all of them (using distcc i couldn't use a generic -march=native) (this is to explain why i use both make.conf on purpose) I'm sure many use this feature to handle lot of hosts easy. (In reply to comment #2) > As soon as feature is deprecated (i hope far far far later) i will have to > find another solve. I've already given you two different ways to use multiple files for make.conf, so what's stopping you from using them instead? Note that if you're doing it for compatibility reasons, you can symlink the two files and that won't trigger the warning. > But until then, that message is useless, i didn't saw it until now, but > revdep-rebuild also spam it, and much more than just 3 times. The rationale for the message is that existence of both files is likely to indicate misconfiguration (maybe the users is unaware that the second file exists). > Could we have an option to disable it, you know for the ones that know what > they are doing using a deprecated feature that might disappear one day, but > like it this way. > (and maybe put a more explicit message for other that don't know what they > are doing) Please explain why you would want to continue using both locations, despite the alternatives that I've given. > I don't have any example to gave, but this kind of change may affect users > using script that parse emerge output too. This is not an issue because the error message goes to the stderr stream, which is practically never parsed by programs (they only parse the stdout stream since that's the standard practice). > Could this issue be solve with a news instead (lol ok sorry, i didn't check > if any news was made already, so if it's already done, i agree it's a good > idea then) This warning has been around for some time and you're the first person to complain, so I'm afraid that a news item would be useless to the vast majority of users. We already have this related news item: http://sources.gentoo.org/gitweb/?p=proj/gentoo-news.git;a=blob_plain;f=2012/2012-09-09-make.conf-and-make.profile-move/2012-09-09-make.conf-and-make.profile-move.en.txt;hb=HEAD :D "This is a change in the installation defaults, that will only affect new installs so it doesn't affect current systems." I knew i could source another file to keep the feature : /etc/portage/make.conf real that source "fakemakeconf" and /etc/portage/fakemakeconf symlink to my shared make.conf But how could i make sure "fakemakeconf" values will get overwrite by make.conf sourcing it at start or end or another trick? I tried that mv /etc/make.conf /etc/portage/make.conf ln -s /etc/portage/sharedmake pathtoservermakeconf add SOURCE="/etc/portage/sharedmake" to end of /etc/portage/make.conf add CFLAGS="bork" in /etc/portage/sharedmake and emerge --info is giving me the CFLAGS from /etc/portage/make.conf where i expect CFLAGS="bork" I tried add the SOURCE line at first line of the make.conf without any changes. There's something i'm not doing right, can you help ? Hi, could please somebody from gentoo dev team take a look into this? It is really annoying as I need to have /etc/make.conf common to all systems while local admin could make minor changes via /etc/portage/make.conf and even if in MAN pages (https://dev.gentoo.org/~zmedico/portage/doc/man/make.conf.5.html) is stated that those two files can co-exist without problem, it is still showing this warning. Please remove this check and warning message. Thank you! p.s. have a nice Christmas! :] (In reply to Martin Cmelik from comment #7) > could please somebody from gentoo dev team take a look into this? > It is really annoying as I need to have /etc/make.conf common to all systems > while local admin could make minor changes via /etc/portage/make.conf and > even if in MAN pages > (https://dev.gentoo.org/~zmedico/portage/doc/man/make.conf.5.html) is stated > that those two files can co-exist without problem, it is still showing this > warning. mkdir /tmp/make.conf mv /etc/make.conf /tmp/make.conf/00base mv /etc/portage/make.conf /tmp/make.conf/99local mv /tmp/make.conf /etc/portage/ This is the supported way. Hi, man pages clearly stated files, not directories. If this is working solution, please update then man pages, so others will not be confused. Thank you (In reply to Martin Cmelik from comment #9) > man pages clearly stated files, not directories. If this is working > solution, please update then man pages, so others will not be confused. Yes, we should update the make.conf(5) man page, and also this part of the portage(5) man page: /etc/portage/ Any file in this directory that begins with "package." or is repos.conf can be more than just a flat file. If it is a directory, then all the files in that directory will be sorted in ascending alphabetical order by file name and summed together as if it were a single file. I have a patch for the man pages in the following branch: https://github.com/zmedico/portage/tree/bug_463266 I've posted it for review here: http://thread.gmane.org/gmane.linux.gentoo.portage.devel/5043 (In reply to Zac Medico from comment #11) > I have a patch for the man pages in the following branch: > > https://github.com/zmedico/portage/tree/bug_463266 This is in the master branch now: https://github.com/gentoo/portage/commit/1d267aa670e7773b31bb88fc285dec9819fd9770 Fixed in 2.2.16. |
