1 |
On Saturday 30 April 2005 02:44, Robin H. Johnson wrote: |
2 |
> On Fri, Apr 29, 2005 at 09:36:54AM +0900, Jason Stubbs wrote: |
3 |
> > What about the unused `ebuild [ebuild] config`? Isn't that the perfect |
4 |
> > place for this sort of stuff? The only package that I know that uses this |
5 |
> > feature is mysql. There are way more possibilities. |
6 |
> |
7 |
> No, ebuild config shouldn't be abused like this. Say I have an existing |
8 |
> install of mysql, and the package maintainer puts in an updated |
9 |
> logrotate.d file. Running 'ebuild mysql.ebuild config' is meant for NEW |
10 |
> installations only, and it doesn't enable me to take advantage of |
11 |
> CONFIG_PROTECT. I've seen a package where running the config phase when |
12 |
> the package is already set up blows away your existing config. It gives |
13 |
> you a warning first, but how would I then get an updated logrotate.d |
14 |
> file? |
15 |
|
16 |
I can't see how you can call it abuse. There's no requirement that the config |
17 |
phase be non-interactive. On the contrary, it *should* be interactive so that |
18 |
the user is notified about and has control over what can be done. |
19 |
|
20 |
> I see only two viable options. |
21 |
> - Unconditional, use INSTALL_MASK, no RDEPEND on logrotate |
22 |
> - Conditional on USE=logrotate |
23 |
> |
24 |
> The first one is what is generally used in the tree so far. |
25 |
|
26 |
I don't really mind what's done. I'm just suggesting that config can be used |
27 |
for a lot more than what it is at the moment, including being a third option |
28 |
in the above list. My preferred option would be INSTALL_MASK. |
29 |
|
30 |
Regards, |
31 |
Jason Stubbs |