To make system administration it would be nice to support make.conf as a directory in addition to the normal flat file. This is particularly useful when manageing a large number of hosts in an automated setup like cfengine where a base make.conf can be distributed across all hosts with host specific USE or CFLAGS in make.conf.d. Either make.conf.d or just a single make.conf directory similar to things in /etc/portage would work.
Created attachment 95420 [details, diff] patch for make.conf.d Here is a simple patch that adds support for make.conf.d by Eric Searcy (emsearcy@osuosl.org)
you're going to get people asking to not have files included that: - start with '.' - end in '~' - are binary in nature (.zip and crap)
Not sure how useful that is given that make.conf already supoprts a 'source' statement (only real difference being that 'source' doesn't support wildcards).
(In reply to comment #2) > you're going to get people asking to not have files included that: > - start with '.' > - end in '~' > - are binary in nature (.zip and crap) Well, the example patch only looks at *.conf so ending in ~ or .zip would be ignored. But yes, it is stupid and will include dot files. If there is interest in this either Eric or I will try to come up with a smarter patch. (In reply to comment #3) > Not sure how useful that is given that make.conf already supoprts a 'source' > statement (only real difference being that 'source' doesn't support wildcards). > That is the difference. We would happily have implemented this with a source line at the end of make.conf, but having a source line for every extra file would be almost as bad to maintain as just working with a single make.conf.
Created attachment 95612 [details, diff] make.conf.d patch rewrite I've rewritten the patch, moving the logic for this up to the correct place. This version is not horribly broken like the last one and also will ignore files begining with '.' and will still only include files ending in .conf.
Might as well be consistent with /etc/portage/ and allow make.conf to be a file or directory, just using everything within it.
well, if/when you're going that way, please make sure you give the file a sane name and put it into /etc/portage, because that's really where it belongs.
If this gets implemented I agree with comments #6 and #7 for consistency and compability (and make.conf directly in /etc has bugged me for some time already). Also in the patch I see that there is a requirement on filenames ending in ".conf", is there any reason for this?
(In reply to comment #8) > Also in the patch I see that there is a requirement on filenames ending in > ".conf", is there any reason for this? > I required .conf mainly because we are using cfengine to push files into this directory and cfengine's default method for removing a file is to simply rename it to $file.cfdisabed or something silly like that rather than actually removing it. I suppose for upstream portage that restriction should be modified to simply exclude things that end in '~'.
After thinking about this once more I think this is a WONTFIX, mainly due to the implications for external tools that currently use 'source /etc/make.conf' and getting wrong data if this feature is used. While updating them would be trivial in terms of code catching all of them and deploying the updates is a significant task. (this might also be the reason why the shlex 'source' command doesn't support wildcards, as it'd be inconsistent with the sh version) I'm also not really convinced about the benefit of this, most users won't have a use for this, and for large scale setups I'd assume that some preprocessing (e.g. replacing 'source /etc/portage/make.conf.d/* with multiple source statements) isn't out of scope.
(In reply to comment #10) > After thinking about this once more I think this is a WONTFIX, mainly due to > the implications for external tools that currently use 'source /etc/make.conf' > and getting wrong data if this feature is used. While updating them would be > trivial in terms of code catching all of them and deploying the updates is a > significant task. > (this might also be the reason why the shlex 'source' command doesn't support > wildcards, as it'd be inconsistent with the sh version) > > I'm also not really convinced about the benefit of this, most users won't have > a use for this, and for large scale setups I'd assume that some preprocessing > (e.g. replacing 'source /etc/portage/make.conf.d/* with multiple source > statements) isn't out of scope. > That's fine, in my case the need for this has long since been solved by a script that just does cat /etc/make.conf.d/* > /etc/make.conf which works perfectly well.
