I noticed packages which merely install files to /etc/cron.daily create the directory with o+rx permissions, yet cronbase does not. It would be nice if these matched, so checking for correct permissions can be done properly.
From my system: net-misc/apt-cacher-ng-0.7.12: ./etc/cron.daily/ needs mode change: drwxr-x--- -> drwxr-xr-x sys-apps/etckeeper-1.10: ./etc/cron.daily/ needs mode change: drwxr-x--- -> drwxr-xr-x sys-apps/man-1.6g: ./etc/cron.daily/ needs mode change: drwxr-x--- -> drwxr-xr-x sys-apps/mlocate-0.26: ./etc/cron.daily/ needs mode change: drwxr-x--- -> drwxr-xr-x sys-devel/prelink-20110511: ./etc/cron.daily/ needs mode change: drwxr-x--- -> drwxr-xr-x
net-misc/apt-cacher-ng-0.7.12 was removed from the tree in July 2013. Other than that, it uses exeinto/doexe to install into /etc/cron.daily/ sys-apps/etckeeper-1.10 has been superseded twice and its successors also use exeinto (with newexe in this case). sys-apps/man uses exeinto/doexe. sys-apps/mlocate uses insinto/doins (unlike the rest). sys-devel/prelink-20110511 uses exeinto/newexe. On none of my systems, this results in overriding the directory permissions that cronbase sets.
The inconsistency is in the produced binary packages. It seems portage does not attempt to merge it to the real filesystem.
you've lost me. why do any of these packages need o+rx bits in these dirs ? it is up to the root cronjob running to execute these files and it has rx perms on the dirs in question. as Jer noted, the files themselves are +x as needed.
It's a matter of consistency. For example, if man gets installed before cronbase, you end up with a different result than if cronbase is installed first.
... which doesn't matter because cron isn't available. when cronbase is installed, it makes sure the dirs in /etc have the correct permission.
(In reply to SpanKY from comment #6) > ... which doesn't matter because cron isn't available. when cronbase is > installed, it makes sure the dirs in /etc have the correct permission. cronbase has a workaround, yes. The goal of this bug is to track the problem actually being fixed at some point.
seems like a waste of time for a completely non-issue the only way to actually enforce it would be with a QA check in portage