(Alexandre, sorry for the double reply, I only now noticed that my webmail client did not reply to the list)
On 2014-12-15 12:12, Alexandre Detiste wrote: >> On the other hand, if the problem is that the upgrade causes a remove, >> and then some time later the user is going to tidy up by purging cron, > > This is it; everything works fine when you switch packages back and forth; > It's only sometime later when you run a routine "aptitude purge ~c" > that this problem happens. Ah, yes, thanks! I was wondering how/why the purge got called (for this to be an issue), as merely switching back and forth wouldn't cause this. >> Making the files be conffiles of a common package seems like a better >> way to go to me. Agreed > I built this package right now: https://github.com/systemd-cron/cron-base > > And then I tried to merge in the bcron-run bits. > The folders in /etc are handled identically; > but /var/spool/cron/crontabs is owned by cron:cron ... > I don't know how to solve this easily. > > > There are various options: > > - keep only support for > /etc/cron.allow|deny|d|hourly|daily|weekly|monthly in cron-base ; > and duplicate code for /var/spool/cron/crontabs in cron & > systemd-cron (both except a mode 1730 root:crontab folder) > > - share cron-base between only cron & systemd-cron; but not bcron-run (ugly) > > - split cron-base in cron-etc & cron-spool (ugly too); both made from > the same source package; > cron & systemd-cron would depend on cron-etc & cron-spool > bcron-run would only depend on cron-etc I'll talk a look at all these options over the holidays. I don't recall right now what exactly we did to support bcron interaction, but I'm confident a single solution is possible. Another solution proposed by jfs was to factor out the crontab command (which writes to /var/spool/cron/crontabs) from src:cron. Having various cron daemon implementations follows from their differing designs, but there isn't much design to merely writing out a file to a specific directory securely. Perhaps a single crontab implementation could suffice to serve all crond implementations; that would also solve the problem above. > Are such tiny packages going to be accepted in the archive ? > At least they are arch:all ; so while trimming cron $numb_of_arch times, > this would globaly reduce archive size. TBH, I'd expect such a cron-base package to be provided by src:cron, which already ships these files. It's merely a matter of splitting the current binary package into two separate ones. Regards, Christian -- 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/5ba1dfb6c2715002356ab0da21c0e...@kvr.at
