It's a pretty common concept that directories that are used to replace single configuration files use the same name with .d suffix appended. For some reason, Portage does not respect that concept and just names the directories the same way files are named. Besides it being confusing, it means that you can't have a file and a directory at the same time. So if you want (or need) to use a directory, you have to get rid of the original file first, potentially moving it into temporary location, then dropping it back in the subdirectory. Now, if I want to have a tool that dumps one of those files, I either have to ask the user to 'convert' his existing file to a directory manually, or implement the migration logic myself. Which effectively ends up with a number of different tools implementing different kinds of migration logic, better or worse. To solve this problem at least partially, I'd like to request that Portage supports *.d directories in addition to existing files/directories. Similarly to other .d implementations, the *.d directories would be read first, then the actual files, e.g. entries from package.use would override those from package.use.d. This layout is less surprising, and makes it much simpler to deploy *.d directories on existing systems. In this case, the tools and users no longer have to worry about migrating existing entries since they can happily coexist with dumped *.d entries.
*** Bug 305955 has been marked as a duplicate of this bug. ***
As a user I'd like to +1 this. Would very much like to be able to just drop my config in a directory and be done with it. This would also be very useful for the automated emerge tests we run in our overlay. For my use case I think I'd prefer to have the files in the directory override, or maybe append to, the defaults. Also, I was wondering why not go with just a directory where all the config lives (so no separate config file at the same level as the directory)?
