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
(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
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
Alexandre Detiste alexandre.deti...@gmail.com 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
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 deamon with a
On Sun, 2014-12-14 at 15:26:37 +, Philip Hands wrote:
Alexandre Detiste alexandre.deti...@gmail.com 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,
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 --purge, or the
aptitude TUI
Ian Jackson ijack...@chiark.greenend.org.uk 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 current apt with APT
: Russ Allbery r...@debian.org
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
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
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,
Alexandre Detiste alexandre.deti...@gmail.com writes:
: Russ Allbery r...@debian.org
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:
Hi,
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
On Dec 13, Alexandre Detiste alexandre.deti...@gmail.com 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
Alexandre Detiste alexandre.deti...@gmail.com 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.
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
16 matches
Mail list logo
