[Pkg-acpi-devel] Bug#502613: [Pkg-utopia-maintainers] Bug#501662: hal: incorrect upgrade management for removal of runlevel links

Michael Biebl biebl at debian.org
Sat Oct 18 12:09:50 UTC 2008

Kel Modderman wrote:
> On Thursday 09 October 2008 21:52:47 Martin Pitt wrote:
>>> if dpkg --compare-versions "$2" lt "0.5.11-5"; then
>> This must be "lt-nl".
>>> 	update-rc.d -f hal remove
>>> fi
>> That's too blunt. It should at most rm -f the rc{0,6}.d symlinks
>> instead of completely stomping over any customizations the admin might
>> have done.
> Hey Martin,
> I just noticed acpid applied a similar patch (#495544) which was a product of
> the TearDown work, and it also didn't handle the upgrade path (#502613, CC'd).
> What's the best way to proceed here to get these TearDown patches to make
> change on upgrade too before too many patches get applied in Debian that do
> not take care of it?
> I didn't get a reply from my last mail to Michael about how hal package plans
> to fix it, is the current best method to do a:
> if dpkg --compare-versions "$installed" lt-nl "$version"; then
> 	rm -f /etc/rc[06].d/K??$script
> fi
> ?

This would work for insserv and sysv-rc, but not file-rc (but I don't
care too much about file-rc, tbh. And the popcon stats of file-rc do not
justify any special treatment of file-rc imho).
It also doesn't take into account any local modifications to the stop
priorities (when using sysv-rc alone). We are thus not 100% policy
compliant,  but I think we can ignore that in that special case.

The major complain I got on debian-release (when we discussed the same
topic for avahi-daemon) was, that the "update-rc.d remove" approach
didn't preserve disabled services, which the above method would do (i.e.
services which were disabled before the upgrade were enabled again

So in summary, I think the suggested method above would indeed be the
best we can do atm.


Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-acpi-devel/attachments/20081018/a9e698c3/attachment.pgp 

More information about the Pkg-acpi-devel mailing list