On Fri, Jun 18, 2010 at 12:29:42PM +0200, Holger Levsen wrote:
> reassign 562945 tech-ctte
> # unmerge 506898 224509
> # policy-maintainers, I think you should do this ^
> thanks
> for those coming late to the party: this bug is about a package which fails to
> install cleanly:
> Unpacking runit-run (from .../runit-run_1.1.1_all.deb) ...
> dpkg: error processing /var/cache/apt/archives/runit-run_1.1.1_all.deb
> (--unpack):
> subprocess new pre-installation script returned error exit status 1
> Errors were encountered while processing:
> /var/cache/apt/archives/runit-run_1.1.1_all.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> Read the bug log for all it's glory.
To summarize for the list, the issue here is than runit-run asks this
debconf question in the preinst:
Template: runit-run/install
Type: boolean
Default: false
_Description: Really replace the init scheme?
This package diverts sysvinit's /sbin/init program, and so replaces
the default sysv init scheme. After the first installation of the
runit-run package, migrate essential services from sysvinit to runit,
so that these will get started after reboot. Then, use
# /sbin/init.sysv 6
to reboot the system with runit as process no 1.
.
Please read the documentation before proceeding
http://smarden.org/runit/
and if the answer to the boolean question is "no" (the default), the package
installation is aborted.
This is explicitly allowed by current Policy (packages may require a
controlling terminal for interacting with the user), and by Policy as it's
supposed to be (bug #506898, packages may abort installation if they fail to
get an answer from the user to a high-urgency question with no sensible
default answer).
Personally, I don't think runit-run's behavior here is what's intended to be
allowed under Policy. IMHO, if the question is "do you want to install this
package that you selected for installation?" the sensible default answer is
always "yes", and if the maintainer isn't comfortable using this as a
default answer because of concerns that their package will break the user's
system, then that points to much larger bugs in the package's integration
into Debian than just this one Policy issue. I don't think a package whose
successful installation results in the system being rendered unbootable
unless further action is taken is up to Debian's quality standards, and
don't think such a package should be included in a Debian release until
someone puts together policy-compliant infrastructure to let the init script
migration happen at package install time.
However, that doesn't seem to be the question that's been put to us.
> While everybody is free to disagree with me, I think there are some parts of
> policy which must not be violated, as we care deeply about unattended and
> automated installs. So I'm reassigning this to the technical committee to
> decide this.
Caring about unattended and automated installs is not the same thing as
mandating that all packages in the archive be installable noninteractively
without preseeding. It's clear to me that a package such as this is not
useful to include in an automated system installation without a *lot* of
additional scripting (the debconf preseeding would be the least of your
worries), and it should never appear as a build-dependency (direct or
indirect) of any other package. And while I understand that this means you
can't get useful piuparts results for this package, once again, I think this
package has much graver quality concerns than piuparts cleanliness - and
anyway, piuparts ought to be extended to support preseeding for this class
of package.
In summary, my proposal would be to:
- decline to override the runit-run maintainer, whose use of debconf is
discouraged but /not/ forbidden by Policy
- advise the Policy maintainers to proceed with the existing proposed
language regarding high-priority prompts
- refer the question of overall releasability of runit-run to the Release
Team
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature