On 9/30/20 10:36 PM, Zbigniew Jędrzejewski-Szmek wrote: > 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.) Why is it important to require resolved in main package? It contains both daemon and lookup tool, couple of bash completion scripts and manual pages. Reason to split it out was stated already: some people won't be using it. It is not so small, 650k deserves own package IMHO. I think only nss-resolve has reason to be kept in main package to prevent issues with nsswitch configuring. I think over half megabyte tool, which only says: not running, sorry!, is not useful. > > (*) 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. We don't talk about allowing it installed. We demand possibility to uninstall it. systemd itself should be installed everywhere for a good reason. There is no alternative for it in Fedora. That is not true for systemd-resolved. It must not be hardwired. There exist more alternative resolution paths. It has to be possible to switch between them. Just for that reason, it should be in separate and uninstallable package. To ensure it is not too hardwired into the distribution without a good reason. > > 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. Weird postinstall snippets are good reason to move it into separate subpackage. It makes it clear which part is related to systemd-resolved, which part is related to systemd itself. > > 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. Please make. Are there bugs for it? Can we help? > > Zbyszek > Cheers, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@xxxxxxxxxx PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
