On Tue, 27.01.15 16:18, Christian Seiler (christ...@iwakd.de) wrote: > 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.
it's more complex than that, since dependencies can come from "both sides", and are generated automatically even. If we really wanted this to work, we'd have store precisely if a dep belongs to the soource or the destaination of the dep, if a dep comes from configuration, or is automatically created, and that we never coalesce deps. But I am not I like the complexity of that, and in particular the fact that we couldn't coalesce anymore... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
