On Mon, Mar 30, 2015 at 12:11:34AM +0200, Matthias Maier wrote: > > > Thoughts? > > One point in favor of the current practice (installing add-on files > unconditionally) is the fact that you can basically do it for free - you > neither have to depend on additional packages, nor is the presence of > the add-on files a penalty in download time or storage.
The add-on files i'm talking about are not specifically used by the packages that install them. They are add-ons that hook the packages into external functions, such as shell completions, logrotate files, xinetd configurations, etc. The penalty is cruft on the users's systems when they don't use the programs that read these files, such as app-admin/logrotate, sys-apps/xinetd, etc. All I'm saying is if the application that processes these small files is not installed, I don't think the files should be either, unless the upstream build system forces it; I guess we shouldn't try to do anything about that. > Further, a lot of packages install _small_ additional files > unconditionally - let it be examples, minimal documentation, example > configurations - unconditionally. And this is done with the very same > reasoning as above; the penalty is small enough to not warrant the > introduction of a use flag. The small files I'm talking about, technically, aren't used by the package that installs them; they are used by another package, which may or may not be installed, independently from the package that installs the small files. > Personally, I would not introduce yet another set of global use flags > just for the sake of controlling everything with use flags. The > complexity this introduces (naming choice - enforcing the rule - > ensuring uniformity) is worse than the current behavior of just > installing small add-on files. Actually I'm not talking about introducing more use flags; the flags I'm interested in adding this functionality to are already there. William
signature.asc
Description: Digital signature
