On Sat, 28 Jan 2006 18:58:52 -0800 Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> You want people to recompile the whole package to get another > text file installed? When would one recompile a package just for that? Only case i can think of is when someone who already has setup his apache / ftp / database / whatever server suddenly discover what "logrotate" is and thus decide to start using it, whereas until then he didn't payed any attention to the flag each time it was listed by "emerge -pv". That sounds rather unlikely, and i would say "too bad, be more careful next time..." to such a sysadmin. And anyway, this user doesn't really have to recompile anything to fix his mistake: he can still have a look on the ebuild to see that if the file he is missing is available in $FILESDIR, or use "ebuild unpack" and get it from the sources tree when it comes from upstream. So no, i don't really see what the problem is here. (Sure, introducing the flag in an ebuild when doing a bump doesn't count as a "recompilation to get logrotate", since that's an update that the user will do anyway.) > People who don't want it can set INSTALL_MASK. It should be > installed by default and not switchable with a USE flag. USE flag is the only way to indicate that a package has logrotate support, and that's important. Remember that files added to an /etc/something.d/ directory are chunks of configuration merged with the user's one. First time they are installed, they are just like bypassing the etc-update protection. I remember that, maybe 2 years ago, syslog-ng suddenly started to install a logrotate.d file, with no USE flag. Sure i didn't noticed it, until i saw that what i had already configured by hand in a different file was not working has expected anymore. Ok, that's just logs rotation, it doesn't hurt that much, but still, i would have prefer it to be introduced along with a USE flag, so that i can notice the change and decide whether i accept it and adapt my configuration. INSTALL_MASK is not of any help against that: how does one know what to mask before it's too late? I use logrotate, i have the flag turned one, and i just can't mask the whole directory, because files i want files that i know are installed there (and want their updates). But next time a package gets added unconditional logrotate support (or i install one which already has it), it may randomly screw my own config again. As for xinetd, i don't use it so i don't really care, but i guess the same arguments could be used: if i was using it, i know i would not appreciate to see it suddenly handling a new service because a xinet.d file has been silently added by a new version of an ebuild. So, really, i currently see the USE flag as the only way to give users control over their /etc/something.d configurations. Or there should be a new config protection mechanism in portage to avoid auto-merge of some of the config files (something similar to CONFIG_PROTECT, like merging them as ._new0001_foobar when they don't exist yet, but with a different paths list, limited to /etc/*.d/ directories). But that's a different story... -- TGL. -- gentoo-dev@gentoo.org mailing list
