On Tue, Jun 28, 2011 at 12:32, Miklos Vajna <[email protected]> wrote: > On Mon, Jun 27, 2011 at 06:23:23PM +0200, Lennart Poettering > <[email protected]> wrote: >> On Mon, 27.06.11 17:37, Ludwig Nussel ([email protected]) wrote: >> >> > Frederic Crozat wrote: >> > > [...] >> > > %service_add_enabled() >> > > if [ "$1" -eq 1 ] ; then >> > > # Initial installation >> > > /bin/systemctl enable %{1}.service >/dev/null 2>&1 || : >> > > fi >> > >> > Does this have an advantage over installing the symlink at build >> > time already and including the symlink in %files instead? >> >> It doesnt right now. But it might eventually: it might be useful to send >> out notification events via the bus when a new service is enabled, to >> allow live views in UIs. > > If the symlink would be part of the package, then a regular package > upgrade would re-enable the service which might have been disabled by > the user in the meantime. Doesn't this sound like an advantage right > now?
Right, it doesn't cover: [ "$1" -eq 1 ], which it should. Packaging enable-links in /etc/systemd should just be %ghosted not installed. Services which can not be enabled/disabled like udev, D-Bus, systemd-internal services might install the links directly to /lib/systemd/system/, but that should never be done for /etc. Anyway, when we think about general service integration into package management, I like to see something like some 'product package defaults' included from the first step on, or at least have thought about them and prepared the hooks in the same way we would use them, when such defaults would exist. It does not make much sense to encode the enabled-at-install, enabled-on-update, started-at-install, restarted-on-update flags into the spec file, it should all be derived from some database that comes along with the system to be installed. Encoding such distro/product policy in the spec file is a bad start. General distros have several products based on the same package, and products might differ completely in the policy they apply to packages. The server product might have very different services enabled/disabled by default than the Live-CD, but they have exactly the same packages. I think %service_add() vs. %service_add_enabled() and so on, is nothing that should be done in the spec file, or which should differ from one service to the other. These calls should all be one and the same generic macro, and the policy should be executed behind the macro, depending on the product, not depending on the spec file. Thanks, Kay _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
