On Mon, Nov 10, 2014 at 02:39:28AM -0500, Gedalya wrote:
On 11/10/2014 02:19 AM, Steve Langasek wrote:
It's not for the sysvinit-core package to fix up the installer's handling of
consoles, when sysvinit-core is not installed. Reassigning this to the
debian-installer package.
And how could it possibly be debian-installer's job to modify a file that is
part of your package, when the package is not installed?
I find your response incomprehensible. This bug is about making sure
inittab, part of sysvinit-core, supports the console on the platform is is
running on.
Currently sysvinit-core is defective in not doing so. My comment about
debian-installer was just so that you could see an example for code that
handles this, and it explains why the maintainers of this package
coincidentally haven't had to worry about this problem thus far.
One way or another, to reproduce this problem all one needs to do is to
install sysvinit-core on a xen VM, with debian-installer nowhere in sight.
I also don't understand why #745260 was fixed (exactly the same problem) and
this one somehow not.
Ok, I misunderstood what the bug was that you were reporting. I thought you
were saying that the installer sets up /etc/inittab, but that this doesn't
cause the console to work on systems where sysvinit-core is not being
installed.
I think fixing bug #745260 in sysvinit-core is dubious; I really think that
the console setup should be done as part of the installer, not as part of
init's maintainer scripts. However, since we are no longer installing
sysvinit-core, it's a legitimate question whether the installer should be
changed to create /etc/inittab on its own if it doesn't already exist, or if
the installer should entirely hand over control of this file to the sysvinit
package.
I think we should get input from the installer team on this.