On 27 January 2015 at 16:47, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > On Tue, Jan 27, 2015 at 03:50:49PM +0000, Dimitri John Ledkov wrote: >> On 27 January 2015 at 15:18, Christian Seiler <christ...@iwakd.de> wrote: >> > Am 27.01.2015 um 15:45 schrieb Zbigniew Jędrzejewski-Szmek: >> >> On Tue, Jan 27, 2015 at 01:36:41PM +0100, Lennart Poettering wrote: >> >>> Dependencies are always additive and coalescing currently. We don't >> >>> track which configuration file or automatic logic created which >> >>> dependency, and hence it is not really possible right now do reset the >> >>> list of dependencies: we wouldn't know what to reset and what >> >>> not. Note that in many cases dependencies can be created from "both >> >>> sides", and if A wants some dependency on B, and B also wants it from >> >>> A, then we coalesce it one. If now some configuration in A wants to >> >>> reset its setting, what do we do with the request from B? >> >> Yes, I think attempting any kind of dependency removal *from loaded >> >> units* would be very complicated, and would require major surgery to >> >> current unit engine. And things would become conceptually more >> >> complicated, >> >> which we certainly don't need. >> >> >> >> But masking of .wants/ links is something different I think. It is a >> >> *localized* modification to a single configuration file. We currently >> >> allow overridding of almost all configuration (units files, files in >> >> .d directories, recently even generators), but .wants and .requires >> >> are an exception. I think we should allow this. Apart from current >> >> use case, it would things more consistent for the user. >> > >> > Additionally, not considering .wants/ but drop-ins: currently, all[*] >> > lists except dependencies can be overridden in drop-ins by resetting >> > them first. So if I write >> > ConditionPathExists=/foo >> > in the unit file, and then >> > ConditionPathExists= >> > ConditionPathExists=/bar >> > in a snippet, that will work as expected. Not so for dependencies. >> > >> > The problem here is I think a bit in the parsing logic: when parsing a >> > unit file, dependencies are immediately added to the unit in question. >> > >> > If you were to first collect them as a set and then only after all >> > drop-ins / etc. of a unit file are parsed you would add them to the >> > unit's dependencies, this would immediately solve the problem. >> > >> > Also note that if b.service as Before=a.service, I would NOT expect and >> > empty After= in a.service to override that, it would be weird. This is >> > another good reason to first collect stuff locally (and only do >> > overrides on that level) before adding the global state at the end of >> > parsing. >> > >> > Or to put it this way: if you take the following things: >> > - the unit file itself >> > - all drop-ins >> > - all .requires.d/ >> > - all .wants.d/ >> > you could combine them (according to precedence rules) to a single large >> > unit file and only then process that. This is at least what I think is >> > a good way to model this, and that's how I modeled it in my head as a >> > user before I looked at the code, when I realized that that's not the >> > case. If you make the code work in a way that respects that model, I >> > think that a lot of things about overrides become much more consistent. >> > >> > Just my 2 cents. >> >> >> Well i thought that if below are implemented: >> http://lists.freedesktop.org/archives/systemd-devel/2014-December/026026.html >> http://lists.freedesktop.org/archives/systemd-devel/2014-December/026042.html >> http://lists.freedesktop.org/archives/systemd-devel/2014-December/026076.html > Yeah, I think I dozed off at the of that discussion there, thank you for > digging > up the links. It seems everybody is in agreement about overriding > .wants/.requires > symlinks with /dev/null. >
cool. > ... >> Whilst: >> bar.service: [Unit] Wants=!foo.service >> foo.service: [Install]WantedBy=!bar > But this isn't in the mails you linked. Let's get the link-overriding part > done first. > Yeah, that's my "new" proposal as extension to above, to keep .d as capable as .wants/.requires. Sure, I'll keep this open for discussion/agreement and will not be implementing just yet. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
