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.
... > 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. Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
