Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

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

 



On Tue, 24.08.10 13:28, Bill Nottingham (notting@xxxxxxxxxx) wrote:

> 
> Matthias Clasen (mclasen@xxxxxxxxxx) said: 
> > > BOOTUP
> > > - System boots successfully to GUI, when configured.
> > > - System boots successfully to text mode, when configured.
> > > - System properly handles being passed [1-5], 'single', 'S', 's', '-s',
> > >   booting to the appropriate 'runlevel' (0 and 6 can still work,
> > >   but they're sort of pointless anyway) When booted in this manner,
> > >   '5' will bring up a GUI, and '3' will not.
> > 
> > You mean 'being passed on the kernel cmdline', I assume ?
> 
> Yes.
> 
> > Do we consider interactive boot essential (I think not) ?
> 
> This seems rather complicated, given the parallel nature of how systemd
> starts things.

You can actually use systemd.confirm_spawn=yes on the kernel
cmdline. This should work fine for an interactive boot and things are
synchronized via tty ownership. However, I am not sure how useful this
all is, given that we starte gdm pretty early (which then owns the
console tty and hence makes it impossible to ask any further questions
which then timeout) and this options asks a confirmation question for
*everything* we start, not just sysv services. That means you get even
asked on shutdown, and when we activate bus services.

systemd.confirm_spawn=yes is a debugging tool, but I don't think this is
useful for a broader audience or ever could be made useful for a broader
audience.

Unless we introduce some kind of interactive UI that somehow doesn't
clash with gettys or gdm being active on a tty I don't hink we can ever
make interactive boots work again.

> Yes. The idea is that if someone writes a systemd unit file today, they're
> not going to need to change its syntax, or where they put it, or how they
> enable it in future releases, unless they're changing it to use *new*
> features of systemd.

My plan is to stay compatible with the file format used in the final
F-14 for subequent releases. While we might rename an option or make an
option redundant we will continue to read the old configuration then and
do the right thing.

> I meant 'as booting in upstart on the same release'. It's still an option
> in the F-14 branched tree.
> 
> > > -- The services shall function the same.
> > 
> > This is again not really much of a systemd requirement.
> 
> It's a place where systemd can cause regressions due to the change in
> how services are started. See the current (now fixed?) NetworkManager
> problems.

Grmbl, let's also note one thing: if LSB headers of init scripts are
incorrect of arbitrary packages I don't want to be held responsible for
that either. The LSB data must be "more correct" than it used to be. But
that's not a bug in systemd...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux