On Mon, Oct 27, 2014 at 02:16:38PM +0000, Colin Guthrie wrote:
>
> Zbigniew Jędrzejewski-Szmek wrote on 27/10/14 13:52:
> >> [As a side note, if this is the recommended approach, then we should
> >> probably add appropriate RPM macros to macros.systemd for user unit
> >> presets...]
> > Good point.
>
> I usually get one or two a year ;)
>
> >> There are, however, two questions still remain:
> >>
> >> 1. As we have two units, pulseaudio.socket and pulseaudio.service, and
> >> as the desired behaviour is to enable only the socket but not the
> >> service (i.e. by default rely on socket activation - don't waste
> >> resources unless a client actually connects; this is a bit of an
> >> assumption - perhaps this should be desirable?) should we:
> >> a) Recommend packagers only call "systemctl preset --global
> >> pulseaudio.socket"
> >> b) Recommend packagers call "systemctl preset --global
> >> pulseaudio.socket pulseaudio.service", but remove the [Install] section
> >> from the .service
> >> c) Recommend packagers call "systemctl preset --global
> >> pulseaudio.socket pulseaudio.service", but ship a preset file in
> >> /usr/lib/systemd/user-preset/50-pulseaudio.preset that has "disable
> >> pulseaudio.service" in it.
> >
> > Neither of those. Distribution packaging should set the default
> > policy, which in case of Fedora would be 'disable *', and
> > the package specific policy, containing just 'enable pulseaudio.socket'
> > assuming that only socket activiation is desired.
>
> So: d) Recommend packagers call "systemctl preset --global
> pulseaudio.socket pulseaudio.service" and ship separately the global
> distro-wide preferences in another package?
Yes.
> > This way, full flexibility is retained, and distributions like
> > Fedora that don't activate by default on package installation, and
> > the ones like Debian that sometimes do, attain desired behaviour
> > by simply chaning one or two lines in the presets files.
>
> My main point was not really about the "enable by default or not" type
> policy of presets, but rather what happens when you have socket+service
> combos.
>
> If your distro policy is to "enable by default", then is there a better
> way to handle the case where you only want to enable sockets for the
> services, but not the services themselves.
I don't think that there is a sensible policy encompassing all
socket+service combos. I expect each case to be handled on its own merits.
This means that having explicit lists of
enable service a.socket
enable service b.socket b.service
...
is unavoidable.
> >> Perhaps there are other socket+service pairs where this makes sense too
> >> however, and this should be encapsulated in the preset logic more
> >> generally? (i.e. the default logic is "if a .service unit is set to be
> >> enabled, double check to see if it has a corresponding .socket unit
> >> which will be enabled and if so, skip enabling the .service".
>
> Basically, is the above something to cater for at a higher level in the
> distro policy or not?
No, imho.
> >> 2. On factory reset, I do not see any calls to systemctl preset, for
> >> either the system or user units. Am I missing something or is this
> >> something which should be part of the factory reset logic (i.e. a unit
> >> with ConditionNeedsUpdate=/etc to call systemctl preset - if so, it
> >> would presumably also need to reload systemd if any work was done for
> >> system units, but we can assume this is safely completed before any user
> >> instances kick in).
> > I seems this should be done. I thought that factory-reset already does
> > that...
>
> Perhaps it does. I didn't see any obvious units when searching for
> ConditionNeedsUpdate in the systemd git tree, but perhaps this is
> achieved in a different way? I didn't search too much more than that so
> could easily have missed it.
Zbyszek
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
