On Tue, 16.07.13 18:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> > On Tue, Jul 16, 2013 at 05:08:12PM +0100, Colin Guthrie wrote: > > 'Twas brillig, and Lennart Poettering at 16/07/13 17:01 did gyre and gimble: > > > Anyway, does that RPM macro sound good to you? > > > > Sure, seems close enough :) > > > > I can do a mass update to all our packages anyway so the slight change > > in syntax isn't a problem. > Hm, can we take a step back for a moment? It seems that the rpm macros > are a fairly complicated solution, and they also don't carry over into > debian or arch. User mode sessions also will not work with rpm macros. Well, it's easy to come up with similar macros for debhelper or arch... User session don't really need this, as there as user daemons usually create the dirs they need on their own and there are no privileges involved which might forbid this. I have commite the RPM macro fro now, since either way we will need it for the packages where the dirs need to exist all the time. > > I am not too concerned about unused runtime directories. After all this > > is not something that would (or even could) grow without bounds. There > > will never be more than O(n) runtime directores for n being the number > > of packages you have installed (or had installed). > Sure, but this n can be around a couple hundred I'd image when debian > is fully converted and installed. For efficiency this is probably > unmesurable, but as an admin I'd prefer not to have hundreds of empty > dirs in /run. On my (pretty much fully converted) Fedora I currently have 20 tmpfiles snippets around. I doubt on an everage Debian machine this would grow much larger. May 40 or so, but that's still not much. > > However, I am not convinced that allowing tmpfiles to be denoted in unit > > files would be a good thing though, because it sounds unnecessary. It > > really sounds as if the daemons which need that should rather create the > > directories on their own before making use of them. This should > > generally be the most robust solution. And in such a case there's no > > need to denote anything about this in the unit files at all... > > Well, we seem to be using the tmpfiles mechanism quite a lot. And > there are good reasons for that: we get a lot of flexibility with a > powerful syntax, and actually there's significant downsides to putting > all this logic in daemons, e.g. support for various xattr > mechanisms. We want to simplify daemons. Also, as you mentioned, some > stuff runs unpriviledged. I want daemons to be robust. So if possible I think daemons should do these things on their own. This also has benefits for systems like selinux where the label for files can be determined using the normal security transitions, rather then databse checks like we currently need to do it... > Also, we could grow a mechanism to *remove* dirs after the daemon is > stopped. Putting it in rpm specific mechanism removes this possibility. I can see how this could be nice but it kinda reminds me of the situation regarding removing UIDs from /etc/passwd after package deinstallation, which is soemthing that is simply very hard to ever get rid, and which is why Fedora is not doing this at all... Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel