Lennart Poettering (mzerqung@xxxxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
