| 1 |
Chris Gianelloni wrote: |
| 2 |
|
| 3 |
>Basically, if the package *requires* something to function, such as a |
| 4 |
>cron script, then it should install it unconditionally. If it does not, |
| 5 |
>then it shouldn't install it. Having to change USE to get a stupid |
| 6 |
>cron/logrotate file is definitely not the best option. Why not install |
| 7 |
>it to /usr/share/doc/$package as $package.logrotate and tell the user |
| 8 |
>about it instead? The only case mentioned where the logrotate USE flag |
| 9 |
>changes functionality is squid, so it should keep the logrotate local |
| 10 |
>USE and everything else should drop it, then copy the logrotate files |
| 11 |
>into /usr/share/doc. That way I don't have to --newuse and recompile a |
| 12 |
>package just to get a simple example logrotate file, things don't get |
| 13 |
>shoved into /etc without consent, and everybody is happy, right? (Yeah |
| 14 |
>right... :P) |
| 15 |
> |
| 16 |
> |
| 17 |
> |
| 18 |
Well, the only reason squid installs a cron/logrotate file is because of |
| 19 |
the sentence <quote>your package ... is supposed to "just work" for the |
| 20 |
end-user</quote>, which at that moment I understood it as a requirement. |
| 21 |
Without it, a fresh squid install needs to be tweaked by the user |
| 22 |
(unless you don't mind to have an ever increasing /var/log/squid/* log |
| 23 |
files). |
| 24 |
|
| 25 |
As for --newuse forced recompilation of squid, do you think people will |
| 26 |
just keep switching logrotate USE flag? Agreed, it could happen once, |
| 27 |
but that's it! |
Archives