Re: one package altering other package's postrm

[Guillem Jover <guillem@debian.org>]

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/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.

Yes, this is the only correct solution, anything else is just less bad.

> >   * 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?

Well, if the conclusion is that at least those two files are a shared
resource, which they seem to be, because they are never created by any
package, but are somewhat the responsibility of a cron implementation,
then I think it makes sense, as a temporary workaround, to take into
account if there are other cron implementations around and not remove
them. Of course the problem with this approach is that you need to
hardcode the list of current cron implementations in the archive in
all other cron implementations, which does not scale and is not
future-proof. But better than removing the postrm, because that
will disable any other cleanup the other package needs to do now or
in the future on removal/purge.

> 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.

The problem here is that those files are not "its stuff". And while
purging on upgrades or by default is really not a good idea, given
how apt is currently implemented (which forces removals before the
new conflicting package gets installed) the situation right now is
a bit worse than what it could be.

Thanks,
Guillem