Re: one package altering other package's postrm
(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
Reply to: