[pulseaudio-discuss] [PATCH 6/8] launch: Add systemd units for launching pulseaudio user instances

[Tanu Kaskinen]

On Tue, 2014-11-11 at 15:50 +0000, Colin Guthrie wrote:
> Tanu Kaskinen wrote on 11/11/14 15:12:
> > On Mon, 2014-11-10 at 16:55 +0000, Colin Guthrie wrote:
> >> Tanu Kaskinen wrote on 10/11/14 16:29:
> >>> Are you sure installing to /usr/local/lib/systemd/user doesn't work? To
> >>> me path-lookup.c looks like it includes /usr/local/lib/systemd/user in
> >>> the unit search paths.
> >>
> >> Hmm, yeah looks like it. It's not documented in the documentation tho',
> >> (I was looking through through "man systemd.unit" which describes all
> >> the paths) and I've not not seen this behaviour in other projects that
> >> support this pkgconfig stuff (and I've seen a fair few when packaging
> >> stuff downstream), so with combined with the fact that this is how
> >> pretty much everything else does things and the fact that the udev rules
> >> already work like this, I don't really fancy introducing something off
> >> the beaten path here, but if you do feel strongly, I can certainly look
> >> into it.
> > 
> > I'll write a documentation patch for systemd, and if it gets accepted,
> > then we could install under /usr/local?
> 
> If we must, but I'd really rather have a defined, clean way to get the
> folder name from pkgconfig for this purpose too, and I really don't see
> why us deviating from the way it's done in all the other projects really
> makes things that much better overall, but if you feel strongly, then go
> for it.

If someone adds a separate pkgconfig variable
for /usr/local/lib/systemd/user, I'm fine with using that, but I don't
expect anyone to add such variable. I think there are very few if any
cases where you'd want to build systemd with a non-standard location
for /usr/local.

By the way, I changed my mind about writing that documentation patch for
systemd. It's not a high priority thing, so I'll postpone that task to
some later time.

> I do think it will be quite hard to support this scheme when you pass
> e.g. --prefix /home/colin/builds/pa/ and it somehow still knows to put
> the units in /usr/local (obviously it doesn't make sense to use
> $prefix/systemd/user/ as a path as this only works for two very specific
> values of $prefix (three if you count /etc as prefix but you'd have to
> be pretty mad to do that!)).

If I pass --prefix=/home/tanu/foo to configure without any other
parameters, I expect that "make install" will NOT try to write to any
system location. If the prefix points to a location under the user's
home directory, "make install" should not require root access.

Similarly, the default behaviour (i.e. no parameters to configure)
should be a safe install - no overwriting of files managed by the
packaging system.

> Personally I'd rather leave it as it is, and just suggest to people to
> use $XDG_CONFIG_HOME/systemd/user/ when doing their own builds as their
> own user or use /usr/local/systemd/system/user/ when using a /usr/local
> prefix. If logic around this could be made available in e.g. an
> appropriate autotools include that lots of packages could use then
> that's fine by me. I just don't like the idea of every project doing
> something homegrown and different; systemd is providing so much benefit
> from standardising things I'd hate to see that undone with small
> convenience hacks littered around everywhere (even if they are sensible
> enough in principle).

If the "convenience hacks" are sensible enough in principle (not
actually hacks at all), wouldn't it be good to make those "hacks" the
standard? I don't think it makes sense for any software to overwrite the
distro's unit files by default when running "make install".

> So yeah, fixing one problem causes another IMO and we certainly
> shouldn't pretend that using /home/colin/builds/pa/systemd/user/ as a
> path is in any way valid as a default choice.

I'm not so certain about that. I'd say we certainly don't want to try to
overwrite system files by default if the prefix is /home/tanu/foo.

> If it is fixed for this tho', then it should also be fixed for the udev
> rules.

The udev rules case is different, because udev doesn't support rules
under /usr/local. I agree that the it would be good to get the udev rule
installation fixed, but I don't see why it should be tied to fixing the
unit dir case.

As a sidenote, here are my thoughts how the udev rules case should be
fixed: either fix udev so that it can load rules from /usr/local or drop
the udev rules altogether. I'd prefer the latter. The udev rules are
only used to attach some information to the devices based on the device
properties, but the same device properties are available through libudev
too, so we could implement the rules inside PulseAudio. That would have
the benefit that you could install updated rules under your home
directory, as opposed to the current situation that requires root access
to update PulseAudio's udev rules.

> /me never uses /usr/local anyway even for his own builds, so my interest
> in it is somewhat limited, but I certainly won't stand in the way.

I use the default configuration (i.e. /usr/local) all the time.

-- 
Tanu