[systemd-devel] RFC: creating a set of systemd RPM macros across distributions ?

[Kay Sievers]

On Tue, Jun 28, 2011 at 12:32, Miklos Vajna <vmiklos at frugalware.org> wrote:
> On Mon, Jun 27, 2011 at 06:23:23PM +0200, Lennart Poettering <lennart at poettering.net> wrote:
>> On Mon, 27.06.11 17:37, Ludwig Nussel (ludwig.nussel at suse.de) 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