Martin Pitt wrote on 18/11/14 13:52: > Hey Colin, > > thanks for the discussion! Trimming heavily; as you said we should let > some other upstreams chime in too, I just have some followup > questions. > > Colin Guthrie [2014-11-18 13:01 +0000]: >>> * I suppose even wich such a policy the post-installation script >>> still needs to call some systemd-update-policy-mumble-mumble magic >>> to actually apply the new policy? >> >> Well, the *.policy files are simply read when calling "systemctl preset" > > Right. I meant, even with using presets, a newly installed package > still needs to call "systemd preset foo.service" for all the units > that it ships, so that the /etc symlinks are generated. I. e. we > merely replace "enable" (what the current Debian packages do) with > "preset" in the postinst. > > We need to do that as systemd doesn't automagically spot newly > installed units (via inotify or what not) and enable them. > > Or did I misunderstand this?
Oh right I see what you mean. Well the "upstream blessed" RPM way is to call "%systemd_post" macro in your %post script, but (personally) I don't like this as it makes the implementation very much embedded into the RPMs so changing the upstream macro needs a full package rebuild. In Mageia we do something similar but we shell out to a script instead. This allows us to replace the implementation without rebuilding all packages. This is a double edged sword however, as on distro upgrades we've got to make sure the package we ship our scripts in is upgraded before we actually do anything. Longer term, I want to move this to filetriggers. We have been using filetriggers for a while via an RPM patch and it looks like some kind of similar functionality will be (at long last) making it to upstream RPM in the nearish future. I believe .deb supports something like this? If this is the case, I'd use a filetrigger to spot the /usr/lib/systemd/system/*.{service,socket,...} units and then call systemctl preset on them. I've not yet switched over to this logic yet myself (mainly due to lack of time to refactor stuff) so I can't really talk from practical experience yet or highlight any "gotchas" (one thing I do know is that any service start/reload/restart we may do in %post would have to be delayed and left to a filetrigger too because we'd have to do this *after* the call to preset. So I may have to make the current %_post_service macro just write out some kind of state somewhere to say "try to start/reload/restart this service" and then process that state in another filetrigger with the same matching regexp but which runs later in the %posttrans) Sorry if that's a bit RPM specific, but I think the same concepts hold true in .deb. >>> * With that, how would a package then say that it does *not* want a >>> particular unit to get enabled? >> >> The idea is that you don't really decide that at a package level, but at >> a distro level. > > We do (and that policy drives the auto-generated postinst), but there > are always special cases where a package might want to ship a unit > which doesn't get enabled by default. I was wondering how that could > be accomodated. So for that, the package itself could ship its own > preset file, containing a "disable myself.service"? That would make > sense (if I understood it right). Either way, this is certainly the > rare exception. Indeed there is nothing stopping that but it's also perfectly valid to decide this centrally too, and just ship your default.preset file with: disable myservice.service enable * (perhaps the other order is wrong tho' - I can't remember the semantics!) As this is the rare exception there shouldn't be too much churn on this and mentioning things in the default policy that are not installed is perfectly OK (even if it might waste a few extra bits). The ensures the policy (even with it's exceptions) is still managed centrally and individual packagers are not encouraged to deviate from this policy. But ultimately this is just a "recommendation" and there is nothing stopping you being a rebel :D > snipped a bunch of stuff where I was harping on about how things currently work, ignoring your ideas to change the status quo ;) >> 1. It pushes decision making on such policy to be distributed through >> thousands of packages rather than being centralised and thus makes it >> very difficult to do respins and change such policy centrally. > > Right, this can't be done with Debian ATM as postinsts use systemctl > enable. Moving to preset would fix that part. So, thanks again for > pointing that out, this is something that we should do, independently > of the (totally orthogonal) discussion of how to treat wants symlinks > in /etc/ vs. /usr. Cool. >> So I guess my reply to this is, this is OK, and I think this goal is not >> one to aim for. It's "state" information and it should be represented in >> /etc and I don't think trying to reduce this is a good idea (personally!) :) > > Okay. I was wondering if that was merely an oversight, or if there are > people who actually want it the way it is currently. Here is the answer :-) It could be as the /etc/ enablement stuff pre-dates the more aggressive push towards a nice, empty /etc. But that said, the preset stuff was done pretty early and I do still think it's can achieve a nicely structured outcome (albeit retaining the links in /etc) without adding other complications with regards to more complex semantics (and possibly changing semantics currently deployed) and without pushing more burden onto packaging. >> Perhaps teaching systemd-delta or systemctl status to show you the >> preset state would solve this problem? e.g. if it showed something like: >> >> >> [colin@jimmy log (master)]$ systemctl status sshd.service >> ● sshd.service - OpenSSH server daemon >> Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled >> [preset: disabled]) >> >> Perhaps that would help? > > That would certainly help already, as then admins would have *a* way > to check what was changed in the system. Seems Tom made the same suggestion too! :) Cheers 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/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel