Re: one package altering other package's postrm
On Sun, 2014-12-14 at 15:26:37 +0000, Philip Hands wrote:
> Alexandre Detiste <alexandre.detiste@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, even during the freeze;
> > if there were a new RC bug popping up;
> > this could even be included in Jessie.
> > To me too, I guess I could check in preinst
> > [1] that /etc/cron.allow or /etc/cron.deny even exists (by default no)
> > [2] that some version of cron without this patch is installed
> > before deleting cron.postrm as last resort.
As mentioned before, just add a versioned Breaks against the cron
package not supporting that, do not mangle its maintainer scripts.
> If this is something you're expecting to come up during the upgrade,
> then one coud solve it by (assuming that you find that the files exist)
> simply hard-linking them to another name then you can hapilly let the
> untouched postrm do whatever it likes.
>
> Then in your postinst, check for the presence of the backup files, and
> move them back into place if they exist.
If using current apt with APT::Get::Purge=true or --purge, or the
aptitude TUI and marking cron for purge, the conflicting package will
get purged before the other package is even in the picture. If libapt
was using dpkg selections for removals, then dpkg would first remove
the conflicting package then unpack the replacement and afterwards
purge the conflictor, which would allow to do backups of those files.
> 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,
> 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
>
> although that still seems like a bad thing to be doing, but as long as
> you discuss it with the cron maintainer, and ensure that the pattern is
> going to match all versions, then you'll at least only be breaking
> things for downstreams that have decided to change that line for some
> reason.
This also breaks with back and forth switches. Say you have cron, switch
to systemd-cron (which disables the puring in cron), switch back to cron,
purge systemd-cron, and after a while purge cron, leavinge behind cruft.
> Making the files be conffiles of a common package seems like a better
> way to go to me.
They cannot be made conffiles, because their mere existence changes
cron's behavior.
Thanks,
Guillem
Reply to: