On Wed, Sep 30, 2020 at 02:21:19PM -0400, Paul Wouters wrote: > On Wed, 30 Sep 2020, Zbigniew Jędrzejewski-Szmek wrote: > > >the systemd package is getting a systemd-networkd subpackage split out > >that will contain systemd-networkd, networkctl, and the associated data files. > >This was requested by coreos maintainers: NetworkManager is used and skipping > >systemd-networkd allows the installation footprint and potential user confusion > >to be reduced a bit. (By 1.6 MB and an unknown amount, respectively.) > > >The main systemd systemd package Obsoletes the -standalone- packages, so it > >should smoothly replace them whenever it is pulled in. > > In which package will systemd-resolved be? Still in the main rpm. I don't see a good reason to split it out. It can be installed without being enabled (*). And with it being enabled by default in F33, there's even less reason to do so. networkd is a few times larger and likely to grow (we're adding support for new tunnel types, new protocols, and new features all the time. systemd-resolved shouldn't grow too much beyond current size.) (*) In general, allowing packages to be installed without being active is much more robust. If we are depending on a package not being present, it is easy for things go south if something pulls it in as dependency, and we have huge dependency trees, it's sometimes it's impossible to uninstall something because of transitive dependencies. Package need to have a reliable way to preconfigure if they will become active after installation. In fact we already built a system like this presets. But I see you point: it should be possible to opt out of systemd-resolved, and right now that's not entirely functional, because presets only decide whether systemd-resolved.service will be enabled, and the resolv.conf symlink manipulation is not conditionalized on that. I'll make it conditional too. Zbyszek > With enterprise server deployments, DNS will be managed by the network > via resolve.conf to enterprise DNS servers. These servers tend to have > "bind views" for different category of deployments. These deployments > will have no VPN, no mDNS requirements etc. They also do not need (and > most likely do not want) DNS caching. > > I believe it would be useful for kickstart installs to not install > systemd-resolved for these kind of typical server deployments. I think > this is an important use case to support. > > For Desktop systems, it could default to installing systemd-resolved. It > could even default to it for all installs including Server, as long as > the administrator has the option to not install it via a kickstart file. > > It also allows those Destop users that want to use their own validating > resolvers on the end node to uninstall systemd-resolved. > > If there are strong reasons not to split systemd-resolved in its own > package, I would like to better understand these reasons. > > Paul > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
