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

[Colin Guthrie]

Tanu Kaskinen wrote on 18/11/14 10:26:
>>> 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.

No problem.

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

I both agree and disagree! I agree that it should not need root privs
but I also think that if you're really supporting this properly you'd
need to intentionally break some features.

e.g. there is *no* directory the user can use without root privileges
where updated udev rules would be read from. So of the user is hacking
on that part and uses --prefix=/home/tanu/foo then there should be a big
fat warning that udev rule installation has been disabled due to
no-standard prefix or whatever.

It would be very wrong to install udev rules into
/home/tanu/foo/udev/rules.d or similar folder as they would have
absolutely zero effect on the system.

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

Again I do somewhat agree here, but only slightly pragmatically due to
the above problem!

I think to handle this really nicely we need some sort of intelligence
and awareness of --prefix where /usr and /usr/local are handled somewhat
specially.

If --prefix is /usr then all is well;

If --prefix is /usr/local then user systemd user unit paths should be
mangled accordingly and udev rules installation should be completely
disabled and a big warning produced (udev rules cannot live in
/usr/local as this may be a separate partition and mounted after udev
has started).

If --prefix is begins $HOME then systemd user unit paths could be
mangled to $XDG_CONFIG_HOME/systemd/user/ or
$HOME/.local/share/systemd/user/ and a warning produced to inform the
user. As above udev rule installation should be totally disabled.

If --prefix is anything else then udev rule and systemd user unit
installation is disabled and big fat warnings produced.



This is the nicest possible thing to do for the user, but quite frankly
it's a huge amount of effort to go to just to help out a few developers
that can be very easily told just to pass a couple of configure
arguments along with --prefix that control this. It means they will
understand what is happening and not be left with some stale units in a
directory they didn't originality think would be touched and left with a
broken system when they try to revert back to their packaged version.

I think too much automation here is a bad thing for peoples
understanding of how these parts actually work. Requiring users to pass
explicit directories means they stand a better chance of actually
understanding how things work and will know better what is needed to
tidy things up again later.


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

I don't fully disagree, and that's why I suggested that if this kind of
logic is to be accepted it should be done so in an appropriate autotools
include that can be shared, not in some magic that only lives in PA's
configure.ac. This autotools stuff should be included upstream in
systemd if it's going to be done at all.

All that said, I really don't think it's worth it. I've explained above
why I think too much automation here for a very niche use case is a bad
thing. It hides details for people who are already technical enough to
compile up their own code.

I'd rather do something like checking for --prefix of /usr and simply
disabling udev and systemd unit installs if the prefix is anything else
with a printed warning that you should use --with-systemduserunitdir or
--with-udevrulesdir if you want to still install them somewhere.

I think any further automation than that is just folly and trying to be
too clever for our own good and will just lead to users with stale units
on their system (that don't work because they've long since removed the
specified binary from e.g. /usr/local/bin). For every install
convenience, there is an uninstall inconvenience!


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

I'm not sure. If I use --prefix as /home/colin/foo and I get an error
about not being able to write to /usr/lib/udev/rules.d, then this makes
me curious and I find the --with-udevrulesdir argument and I can then be
*aware* of this and know that I may need to copy those files to a valid
location, being careful to backup my system provided files etc. and
restore them again later.

This is a way of exposing that knowledge and one that I have definitely
used before!

That said, I can't really sensibly argue that this is the right
approach! A big fat warning during configure would IMO be the right way
to go, even if I might miss this!

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

It's the same problem. With certain values of --prefix, certain other
paths no longer make sense. A --prefix of /usr/local might work with
systemd user units, but they don't work for systemd system units (these
are parsed before /usr/local might be mounted), so if we ever ship
those, we'll have to behave differently there (same as udev rules).

I'm honestly surprised that it's even supported upstream for user units
and I'm tempted to try and push for it to be removed upstream unless
there is a *really* compelling reason to keep it.

So yeah, I don't see it as any different. /usr is a special prefix for
udev, /usr and /usr/local are special prefixes for systemd user units, a
prefix starting with $HOME could be special for systemd user units, but
honestly, I really think you're trying to be far to clever here to
support a use case that maybe five people in the next ten years will
actually genuinely benefit from.

Documenting it would be the better approach IMO.



> 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 latter is the *only* option. udev rules fundamentally cannot be read
from /usr/local as it may be mounted way after udev starts.

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

Well, yeah, that's a posibility, but it would seem counter intuitive to
me to do this internally just to work around a very minor inconvenience
to a very select few individual who compile up PA from source.

I honestly think you're spending waaaay to much effort thinking about
this when some documentation and perhaps a simple ban for prefix != /usr
for rules and units + a fat configure warning would do effectively the
same thing while informing devs better "how things work" and not leaving
left over files littered around the place that could break their systems
when reverting back to distro provided packages.

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

But /home/tanu/foo sounds so nice ;)

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/