[HEADS-UP] systemd for F14 - the next steps

[Bill Nottingham]

Lennart Poettering (mzerqung at 0pointer.de) said: 
> Example: /lib/systemd/system/syslog.target has this line:
> 
>   # See systemd.special(7) for details
> 
> I am not sure I want to duplicate all documentation in the man pages and
> in the spec fails a second time. If you think a referal like that in the
> unit files won't work then I don't think that anything will ever work.

Honestly, I think that if all systemd.special(7) is is one
by one descriptions of each special target, then it's better
to document them in the targets themselves and drop the man
page entirely.

Again, matter of taste.

> > OK, I was missing a detail here - I was conflating alias with name. What I
> > was noticing was the local.service -> rc.local.service link in /lib/systemd.
> > This is actually just bookkeeping to make sure it overrides the /etc/init.d/
> > service, if I'm now reading this right. I wonder if there's a better way to
> > handle this case other than just creating more Name entries/symlinks (have
> > the daemon do this without the symlink?), but... *shrug*.
> 
> Well, it's just there because the old fedora sysv system is a bit weird
> and used both names at different places. And so we inherited that in a way.

Can't this be solved by just having rc.local executed by a native systemd
file and dropping the explicit Sxx SysV link? (Similar for some other
items.)

> > Given that knowledge, it makes me then wonder what exactly 'systemd-install
> > disable' is supposed to do. I'll check out git.
> 
> Currently it undos the suggested installation, but leaves everything you
> manually added enabled. Might be worth extending to remove all symlinks,
> i.e. for package uninstall. This is now on my todo list.

Yeah, I think we'll need that just to avoid dangling symlinks getting left
around in some cases - even if the user doesn't create random new targets,
they might enable the service in one of the default targets.

> > Well, I like what we have with upstart in that it just requires changing
> > a variable in a config file, rather than filesystem-level changes. Perhaps
> > there's a way to hack that in.
> 
> But that again is a matter of taste, isn't it?

Sort of. I wonder if it's equally similar to represent in config management
systems like puppet. Something to look at later...

Bill