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(a)redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB