[systemd-devel] getty at .service.m4 and serial-getty at .service.m4

[Lennart Poettering]

On Thu, 11.11.10 21:39, Andrew Edmunds (Andrew.Edmunds at yahoo.com.au) wrote:

> Kay, Lennart,
> 
> Kay Sievers wrote:
> > Michael, any chance to check if it's possible to avoid the mangling of
> > common util-linux tool names, and get a symlink in Debian package?
> > After that we can drop the ifdef stuff here.
> 
> We can ask, but it has been that way for at least a decade so I'm
> guessing it's unlikely to be changed now. See this Debian bug from
> 2001, marked wontfix.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=117596
> 
> The Debian position actually seems quite logical to me.  Why do Fedora
> (and SUSE?) need to ship two different versions of getty and hence
> call one of them "alternate getty"?  Other people seem to manage quite
> well with only one.

On Fedora and Suse there is no getty, only an agetty (and mingetty, but
we are phasing that one out too). Upstream and almost all distros call
the binary agetty. Only Debian renames it to getty. Due to that I think
it is smarter and easier to have Debian change back to the upstream name
then have everybody else follow Debians deviation from upstream.

But then again I must admit that the name "getty" is nicer and more
appropriate than "agetty", but that doesn't really matter does it?

> > Hmm, I'd very much prefer if those distros would upgrade their u-l-ng
> > patches instead.
> 
> I'm sure they will, and I was only suggesting this as a temporary fix
> to be removed again later.  Without "-s", you may need to press Break
> to get the correct baud rate but at least a serial console is usable.
>  With the "-s", getty just gives a "Usage:" error and respawns
> continuously so the serial console is completely non-functional as
> things stand.

Maybe as long as the u-l-ng version in Debian/Ubuntu isn't updated it
might make sense to include a patch to this in the package? I really
would like to gently pressure downstream to upgrade u-l-ng, so that we
don't have to carry around compat kludges upstream all the time.

> >> Is there a reason why this applies only to Fedora and Arch?  It seems
> >> > appropriate for all users as far as I can see.
> > 
> > Only Fedora and Arch have rc.local. If you ask me rc.local is something
> > that should just die, hence I am very reluctant to support it on any
> > more distros than we currently support it on.
> 
> Not so.  Here are the contents of /etc/rc.local on an Ubuntu system.
> I believe this file comes straight from Debian.

Hmm, if that's the case, then the units/debian subdir should probably
have a service file for this, and we can include this extra ifdef.

> Anyway, the point of this was only to have getty start late(ish) in
> the boot process, after most of the other services that are pulled in
> by multi-user.target. Maybe there is a better way to specify this, if
> not everyone has rc.local?

Well, since we start everything in parallel and without waiting there
isn't really a point in time where we know we finished start-up. Such a
point simply does not exist.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.