[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab

On Mon, Nov 10, 2014 at 02:41:27PM -0500, Gedalya wrote:
> On 11/10/2014 01:43 PM, Steve Langasek wrote:
> >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.
> >
> I don't really see how it makes sense to create an /etc/inittab when
> we're installing systemd (silently and without asking). Without
> sysvinit, inittab doesn't belong there and doesn't make sense. The
> way I see it, the only way the installer can be of help here is if
> it is changed to prompt the user for his init system choice, which
> AFAIK wasn't the decision so far.. though it would please me very
> much!
> Otherwise we're sort of pre-creating a file for a hypothetical purpose..

Are there any other inits that use /etc/inittab?  With the plethoors of 
inits that have showed up over the past decades, it wouldn't surprise 
me at all if some of them were compatible in this respect.

Would it make sense to put /etc/inittab into annother package that 
sysvinit-core depends on?  The way things look right now, with systemd 
being installed against their wishes, sysvinit users are being told to 
install sysvinit-core after installation, when they have finally booted 
the target system.  This way, /etc/inittab would be installed for them 
at the same time.

Any other inits could have the same dependency, as apropriate.

-- hendrik

Reply to: