Systemd macros (f18+)

[Lennart Poettering]

On Thu, 13.09.12 08:48, Simone Caronni (negativo17 at gmail.com) wrote:

> Hello,
> 
> On 13 September 2012 08:06, Lennart Poettering <mzerqung at 0pointer.de> wrote:
> > Since F16/F17 do not have presets we cannot just port those macros
> > there. What is one macro in F18 would map to two macros in F16/F17.
> 
> Can you please point me to the two macros? I only see a small difference.

On F16/F17 in postinst you have to do "systemctl enable" to enable a
service. To leave a service disabled you do not invoke systemctl at
all. Whether a service is enabled or not after installation is encoded
in the package itself and hence it is up to the package maintainer
whether he includes the "systemctl enable" or not. To turn this into a
postinst macro you'd have to introduce two macros: one with and one without the
"systemctl enable".

On F18 in postinst you have to do "systemctl preset"
unconditionally. Whether a service is enabled or not after installation
is no longer encoded in the package itself but in the preset policy of
the distro/spin/admin. Since there's only one possible operation here
we only have one macro for postinst: the one which invokes "systemctl
preset".

In other words:

A) There's one postinst script that invokes "systemctl enable"
B) There's another one that does not invoke systemctl, and leaves the service off
C) There's a third one that invokes "systemctl preset"

In F16/F17 A and B are used. Some packages use A, most packages use B.

In F18 only C is used. All packages use C. 

In F18 we have a macro that implements C. We have no macro that
implements A or B.

Now, you are asking me to provide a macro with the same name and
functionality in F16/F17 as the one we introduced for F18, right? But
how could we do this? If on F18 the macro implements C, what would it
implement on F16/F17? Would it implement A? If so, it would be useless
for all packages whose service needs to stay off after
installation. Would it implement B? If so, it would be useless for all
packages whose service needs to be enabled after installation.

Of course we could introduce new macros for both A and B, so that we'd
have three macros, covering all three operations. But who'd be helped
with that? We should introduce new stuff only for new distros, and maybe
backport it. But this would be adding completely new stuff to old
distros that makes no sense anymore on new distros, and hence we
shouldn't do it.

Hope this clarifies this a bit.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.