unowned directory problem with /etc/logrotate.d

Thomas M Steenholdt tmus at tmus.dk
Fri Nov 24 22:02:34 UTC 2006


Hans de Goede wrote:
> Hi all,
> 
> Many packages drop config files for logrotate in /etc/logrotate.d. 
> without requiring logrotate, which is the owner of
> /etc/logrotate.d, thus potentially leading to an unowned 
> /etc/logrotate.d for users who don't want logrotate and thus remove it.
> 
> I see 2 solutions for this:
> 1) Add "Requires: logrotate" to all packages which put files in 
> /etc/logrotate.d. IMHO this is not good as the user should be able
>   to choose if he wants logrotate or not.
> 2) Add /etc/logrotate.d to the filesystem package, this is my preferred 
> solution.
> 
> I would like to hear what others think, before filing a bug against 
> filesystem requesting 2) .
> 
> Regards,
> 
> Hans
> 

Requiring logrotate is not really preferred, since people may choose to 
remove logrotate and it does not make any real sense that you can't 
install httpd or cups or others without a pre-chosen log-management 
package (exactly as you point out).

On the other hand, putting /etc/logrotate.d in the filesystem package is 
probably not a too much better, since we will still be installing stuff 
for a particular log-management package, that may not even be there. 
This seems wrong to me.

So since we're already discussing this, what if all packages that put 
stuff in logrotate.d, do so from a sub-package... httpd-logrotate (or 
something)... The -logrotate sub packages should require logrotate and 
of-course the main package (httpd in this case). Users can remove 
logrotate and with it, all the -logrotate subpackages from cups, httpd 
and the rest, but the software will still install and run just fine.
This method has the added benefit of giving us a cleaner way to provide 
log-management for everything, based on an entirely different 
log-management tool. Put <XXrotatelogsXX> in extras and provide a 
http-<XXrotatelogsXX> package and all is good.

Just my .5€s worth

/Thomas




More information about the fedora-devel-list mailing list