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/
