Re: Bug#605912: runit: Upgrade failure lenny -> squeeze
# CC to debian-devel for squeeze blocker
user release.debian.org@packages.debian.org
usertag 605912 + squeeze-is-blocker
thanks
Hi,
Thanks for looking at this bug. I think the patch you've suggested is
the wrong solution, however.
On Tue, 2011-01-04 at 01:14 +0900, Hideki Yamane wrote:
> I guess it is due to lack of flag in debconf templates file.
> Here's a proposal patch, it works in my chroot environment.
[...]
> +runit (2.1.1-6.2) unstable; urgency=low
> +
> + * Non-maintainer upload.
> + * debian/control
> + - add missing depenedency "debconf (>= 0.5) | debconf-2.0"
> + * debian/runit.templates.in
> + - add "runit-run/install" (Closes: #605912)
The code in the config script which sets the runit-run/install flag as
seen (which is where this bug comes from) is guarded by a check for
upgrades from versions >= 2.0.0-1, which is the version in lenny.
However, runit only ever suggested runit-run, so the code was always
broken. As runit-run no longer exists after lenny, I think removing the
entire block of code would be a better solution.
In terms of the second part of the patch, the package's use of debconf
looks a little odd. There is one template, which says "can I signal
init to restart?". Previously, the signalling was performed without
asking, which broke in environments where there was no such process,
such as vservers (see #542593). The implemented solution asks this
question at low priority if an init process is found, and high priority
if not; in both cases the default is "yes", which does not seem to make
much sense in the case where it has already been determined that there
is no such process.
It's possible that I simply need more coffee, but it may make more sense
to simply rip the debconf use back out, and have the postinst signal
init based simply on the existence of an init process.
Comments welcome.
Regards,
Adam
Reply to: