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

[Lennart Poettering]

On Tue, 28.06.11 13:11, Kay Sievers (kay.sievers at vrfy.org) wrote:

> 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.

I agree with this. I'd really like to see someone working on getting
"service enabling profiles" or something like that solved at the same
time as we consider these macros. These two changes to service handling
should probably go hand in hand.

I wonder if we should actually help implementation of this with
systemd. i.e. add a switch "--if-listed" or so to "systemctl enable"
which enables a unit only if it is listed in some profile file in
/lib/systemd/enable or so. Might be something to think about. By default
we would not ship such a file, and hence would leave all services
disabled when this switch is applied, but distributions could just drop
a file in there and ship different versions on livecds, installs, on
desktops, servers and the various spins. 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.