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
