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