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

[Frederic Crozat]

Le samedi 02 juillet 2011 à 01:33 +0200, Lennart Poettering a écrit :
> 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. 

Ok, so based on everybody feedback, here is an amended proposal, which
includes the following changes :
-%service_* macros are expecting full unit name (sshd.service,
foobar.socket)
-%service_add_enabled is no longer part of the proposal, policy for
enable / disable service is out of the scope of this proposal.
-%service_* macros accepts several units files as parameters

(the various macros could be modified by distro if they also want to
support sysvinit service with the same macro, but it is outside the
scope of this initial proposal)

%service_add()
if [ "$1" -eq 1 ] ; then 
# Initial installation 
/bin/systemctl daemon-reload >/dev/null 2>&1 || :
fi

%service_del_preun()
if [ "$1" -eq 0 ] ; then
# Package removal, not upgrade
/bin/systemctl --no-reload disable %{?*} > /dev/null 2>&1 || :
/bin/systemctl stop %{?*} > /dev/null 2>&1 || :
fi

%service_del_postun() 
/bin/systemctl daemon-reload >/dev/null 2>&1 || :
if [ "$1" -ge 1 ] ; then
# Package upgrade, not uninstall
/bin/systemctl try-restart %{1} >/dev/null 2>&1 || :
fi

(this macro could refer to different package, if people don't agree on
systemd-units as packagename)
%define systemd_requires()
# This is for /bin/systemctl
Requires(post): systemd-units \
Requires(preun): systemd-units \
Requires(postun): systemd-units \

%service_migrate_to_systemd(l)
{-l:LEVEL="-l $1 ; shift }
for service in %{?*} ; do \
if /sbin/chkconfig $LEVEL $service ; then
     /bin/systemctl --no-reload enable `echo $service | sed -e
's/\.service//g'` >/dev/null 2>&1 || :
fi

usage :

%post
%service_add demo.service foobar.socket

%preun
%service_del_preun demo.service

%postun
%service_del_postun demo.service

when migrating a package from sysvinit to systemd :
%triggerun -- package_name < version_where_switch_occured
  %service_migration_to_systemd [ -l run_level ] service_name.service
foobar.socket

-l <run_level> is optional

-- 
Frederic Crozat <fcrozat at suse.com>
SUSE