On 2014-12-14 00:36, Guillem Jover wrote: > On Sat, 2014-12-13 at 23:09:08 +0100, Alexandre Detiste wrote: >> This is needed to avoid that /etc/cron.allow & /etc/cron.deny disapears >> when cron is purged but systemd-cron still needs those. (from v1.5.1) >> >> In http://anonscm.debian.org/cgit/pkg-cron/pkg-cron.git/tree/debian/postrm : >> # if [ "$1" = "purge" ]; then >> # rm -f /etc/cron.allow /etc/cron.deny >> # fi >> >> The handover of custom /etc/crontab works fine thank to the "Replace:" >> in d/control > > There are some possible more “correct” ways to fix this, for example: > > * Move the handling of those (and any other) common files or dirs > (like /etc/cron.allow, /etc/cron.deny, crontab.5, /etc/crontab, > the /etc/cron.* dirs and placeholders, and possibly also the cron > spool) to a third package (say cron-common/cron-support/cron-base/etc) > that both packages depend on.
I believe that in the long-term, this would be the most reasonable solution. The cron package currently ships these files but really, these follow from standards and established practices. We already have some smallish hacks WRT to the above-mentioned files and cooperation with bcron; splitting these files out would probably make these hacks no longer necessary. > * Or change cron (and systemd-cron) to take into account each others > presence to not purge those files in that case (although this one > is not future-proof). Isn't it the intention of purge to remove files regardless? I was under the impression that installing systemd-cron would result in a "remove" of cron, and a "purge" would be an explicit request for, well, a purge of all its stuff. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/548d8ffb.9000...@kvr.at
