Re: one package altering other package's postrm

2014-12-15 Thread Russ Allbery
Ian Jackson writes: > Guillem Jover writes ("Re: one package altering other package's postrm"): >> As mentioned before, just add a versioned Breaks against the cron >> package not supporting that, do not mangle its maintainer scripts. > ... >> If using c

Re: one package altering other package's postrm

2014-12-15 Thread Ian Jackson
Guillem Jover writes ("Re: one package altering other package's postrm"): > As mentioned before, just add a versioned Breaks against the cron > package not supporting that, do not mangle its maintainer scripts. ... > If using current apt with APT::Get::Purge=true or --purg

Re: one package altering other package's postrm

2014-12-15 Thread Guillem Jover
On Sun, 2014-12-14 at 15:26:37 +, Philip Hands wrote: > Alexandre Detiste writes: > > I've sent a one-liner patch, as this put the least work on cron maintainers: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773095 > > > > I guess they can apply it right away, even during the free

Re: one package altering other package's postrm

2014-12-15 Thread Christian Kastner
On 2014-12-15 15:56, Alexandre Detiste wrote: >> 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. > > I agree. > > bcrontab does special magic and talk to it's dea

Re: one package altering other package's postrm

2014-12-15 Thread Philip Hands
Alexandre Detiste writes: ... >> then rather than simply removing the postrm, you could edit it, thus: >> >> sed -e 's#rm .*/etc/cron.allow#: &#' /var/lib/dpkg/info/cron.postrm > > I would do that; that's the least intrusive. Oh, I pasted the wrong version of that -- it should have been '-i' t

Re: one package altering other package's postrm

2014-12-15 Thread Alexandre Detiste
> Another solution proposed by jfs was to factor out the crontab command > (which writes to /var/spool/cron/crontabs) from src:cron. That may have trickled down from this mail :-) (should I had CCed you ?) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766053#30 I finally came up with a minim

Re: one package altering other package's postrm

2014-12-15 Thread Christian Kastner
(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 c

Re: one package altering other package's postrm

2014-12-15 Thread Alexandre Detiste
> 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

Re: one package altering other package's postrm

2014-12-14 Thread Philip Hands
Alexandre Detiste writes: >> : Russ Allbery >> Well, ideally this is something that should be coordinated with the cron >> package. > > I've sent a one-liner patch, as this put the least work on cron maintainers: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773095 > > I guess they can

Re: one package altering other package's postrm

2014-12-14 Thread Guillem Jover
Hi! On Sun, 2014-12-14 at 14:26:19 +0100, Christian Kastner wrote: > On 2014-12-14 00:36, Guillem Jover wrote: > > 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/

Re: one package altering other package's postrm

2014-12-14 Thread Christian Kastner
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-

Re: one package altering other package's postrm

2014-12-14 Thread Alexandre Detiste
> : Russ Allbery > Well, ideally this is something that should be coordinated with the cron > package. I've sent a one-liner patch, as this put the least work on cron maintainers: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773095 I guess they can apply it right away, even during the fre

Re: one package altering other package's postrm

2014-12-13 Thread Guillem Jover
Hi! On Sat, 2014-12-13 at 23:09:08 +0100, Alexandre Detiste wrote: > Would it be OK / ugly / forbiden to do a > "rm -f /var/lib/dpkg/info/cron.postrm" > in systemd-cron preinst script ? This would be just wrong and unnecessary. This is not the prerm case in

Re: one package altering other package's postrm

2014-12-13 Thread Russ Allbery
Alexandre Detiste writes: > Would it be OK / ugly / forbiden to do a > "rm -f /var/lib/dpkg/info/cron.postrm" > in systemd-cron preinst script ? > 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

Re: one package altering other package's postrm

2014-12-13 Thread Marco d'Itri
On Dec 13, Alexandre Detiste wrote: > Would it be OK / ugly / forbiden to do a > "rm -f /var/lib/dpkg/info/cron.postrm" > in systemd-cron preinst script ? Ugly, but sometimes there is no other option. I am quite sure that I had to do this once or twice in my packages and no adverse effects have