On Thu, Nov 21, 2013 at 2:39 AM, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > On Thu, Nov 21, 2013 at 02:27:28AM +0100, Tom Gundersen wrote: >> On Wed, Nov 20, 2013 at 10:37 PM, Lennart Poettering >> <lenn...@poettering.net> wrote: >> > On Wed, 20.11.13 14:38, Tom Gundersen (t...@jklm.no) wrote: >> > >> >> Pass on the line on which a section was decleared to the parsers, so they >> >> can distinguish between multiple sections (if they chose to). Currently >> >> no parsers take advantage of this, but a follow-up patch will do that >> >> to distinguish >> >> >> >> [Address] >> >> Address=192.168.0.1/24 >> >> Label=one >> >> >> >> [Address] >> >> Address=192.168.0.2/24 >> >> Label=two >> >> >> >> from >> >> >> >> [Address] >> >> Address=192.168.0.1/24 >> >> Label=one >> >> Address=192.168.0.2/24 >> >> Label=two >> > >> > I do like this solution better, but I can see Thomas' point. And the >> > issue Thomas points out manifests itself in handling of .d/ >> > directories... If we want to support .d/ directories for these >> > configuration files (do we?) then how can we extend the settings of a >> > specific existing [Address] section? >> >> My take was that we do not want to support .d/ directories,
> udev supports overrides, tmpfiles support them too, so do systemd > units, and sysctl settings. I'm pretty sure we can assume that > overrides for network files will happen sooner or later. Also, it's > not just /etc/... overriddes, but also /run/... overrides, for > until-reboot settings. Nah, this is only about fragment drop-ins, they are only supported by unit files. The network files surely support individual files in a directory, but not fragments to overwrite parts of a file. As mentioned earlier, network files are like udev rules, the file name is meaningless, so .d/ fragment drop-ins make not much sense here. Kay _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
