I fumbled with the file list regex a bit, the latest build from koji-ci now shows the sysusers subpackage to contain this:

$ rpm -ql systemd-sysusers-245.5-3.fc33.x86_64.rpm 
/usr/bin/systemd-sysusers
/usr/lib/.build-id
/usr/lib/.build-id/5e/0057dc3ad69b11d32e822aa39b089f70e365bb
/usr/lib/systemd/system/sysinit.target.wants/systemd-sysusers.service
/usr/lib/systemd/system/systemd-sysusers.service
/usr/lib/sysusers.d
/usr/share/man/man5/sysusers.d.5.gz
/usr/share/man/man8/systemd-sysusers.8.gz
/usr/share/man/man8/systemd-sysusers.service.8.gz

Sorry, but this won't work at all like this. systemd-sysusers is linked to systemd-shared-nnn.so, which is part of systemd.rpm. So either systemd-sysusers would need to be compiled without that dependency (which would blow up the size of the binary a lot), or systemd-shared needs to be moved too, or systemd-shared needs to be moved a new package that both systemd-shared.rpm and systemd.rpm depend on...

Thanks for reviewing this! I'd prefer to split out systemd-shared into another subpackage then. The goal of this is to be able to install sysusers with as few dependencies as possible.

That would still pull in all the libraries. So the savings might be rather small.
... I'm not against, but I would like to see how the sizes turn out.

I've split out the libsystemd shared object into systemd-shared, and sysusers and tmpfiles into their own sub-packages, with a dependency on the shared sub-package.

Do sysusers and tmpfiles depend on anything in systemd-libs or is the libsystemd-shared-nnn.so all they need?

I wonder if it would be better to expose a static build of systemd-sysusers (from upstream Meson) and then build a separate RPM package (potentially from a separate spec file) with both the new package and the systemd package providing a working /usr/bin/systemd-sysusers.

(I can think of a similar approach in packages coreutils-single or glibc-minimal-langpack, which I know exist on RHEL 8, and provide alternative versions of their corresponding packages, but with some slightly different build options...)

cqoreutils-single is the only example I know about. glibc-minimal-langpack is just an empty package the satisfies the dependencies. I'm all for having a standalone version if this package. May want a Suggests in place so users normally get the shared version.

See #27 for an alternative approach.

(Note that it requires an upstream PR to be merged and released first.)

Makes sense to me. I'm closing this PR in favor of #27

Reopening this. Can one of the packagers please take a look?

I now feel this is orthogonal to #27

If #27 gets pushed then you'll get a new systemd-standalone package that doesn't depend on any of the other systemd packages (i.e. doesn't pull in systemd-libs) and will contain only two binaries systemd-sysusers and systemd-tmpfiles.

Wasn't that what you really wanted with this PR?

I think I'd like #27 to ship systemd-sysusers-standalone and systemd-tmpfiles-standalone packages separately.

Those would then cleanly conflict with systemd-sysusers and systemd-tmpfiles from this PR.

Yes, we can do separate systemd-standalone-sysusers and systemd-standalone-tmpfiles if you think you might need only one or the other not both in some use cases...

But I don't understand why you think you might still want to break the current systemd RPMs (full installation) to have a separate sysusers or tmpfiles that still depend on systemd-libs. Can you clarify?

In which case would you use the systemd-sysusers or systemd-tmpfiles that depend on systemd-libs in which it's not OK to install the whole of the systemd package with the system manager and all other binaries?

That would allow systems where the standalone binary is installed to also install the rest of systemd later on, without having to replace the standalone binary with the shared one (this is especially useful for rpm-ostree based OSes, where you'd need to explicitly replace the package when installing systemd.

Would the shared, but split out binaries actually require systemd-libs? I was under the impression they'd only need systemd-shared containing only libsystemd-shared which is also introduced in this PR.

I think we can make that work without breaking the packages.

Perhaps by adding Obsoletes: systemd-standalone-sysusers (and tmpfiles) in the main systemd package, then dnf install systemd will automatically remove the other package? (Not sure this is how this works...)

In any case, I think I'd prefer to avoid breaking this down into too many multiple packages, I think there's a certain amount of pain that gets added with each package that you add and I think avoiding that would be good... But I don't know, maybe that's just my 2c...

In any case, looks like we'll get the "standalone" change upstream, and shortly after I'll pick up #27 to see how we can get that one sorted out. (Totally fine with me to split that one into separate packages for sysusers and tmpfiles. And eventually systemctl it seems.)

Cheers!
Filipe

What value does this bring? This seems to be particularly complex for no effective space savings, added complexity for providing systemd services, and makes it difficult to be certain that we actually have everything needed installed in systemd environments.

I'd prefer to change the build config to break systemd-shared.so into 2 parts: one without the extra deps, and a depending one that adds in the separate deps. Then you can make a subpackage of the "core" tools without bringing in all the deps. This would avoid the alternative packages. I find the coreutils-single approach to be sub-optimal, including not inheriting (AFAICT) the FIPS certification for the hash functions, with no link to a certified library (openssl when certified)

We actually have the upstream changes we need for #27, so I'd suggest we should go with that one instead.

The commit in PR #27 creates separate standalone packages for tools people might want to use on non-systemd systems (or containers not running systemd as PID 1) but without affecting the normal installation, which keeps working the same as it does today...

I'll follow up and update that one. Once we merge that, we can look into dropping this one.

@lorbus Please don't split sysusers and tmpfiles into their own subpackages. Instead, if you must split this out, a generic -systools subpackage would be better, since the singular -systools package can be forced into the minimal environment so that scriptlets still work.

@ngompa this shouldn't change how scriplets work -- the systemd main package still requires sysusers and tmpfiles subpackages and therefore pulls them in. This is only intended to add the ability to install them standalone, if needed.

@filbranden I still see this PR and #27 as orthogonal - with #27 one gets a small size benefit when installing stand-alone but one cannot install the main systemd package where those standalone packages are installed without removing them (which is especially important when layering rpms onto an rpm-ostree). This approach here should allow for a conflict-free main package installation on systems where the sysusers and/or tmpfiles sub-package is already installed.

I've split out the networkd sub-package commit #34 since it's not really related to the sysusers/tmpfiles split.

@lorbus We don't have the systemd main package in container base images, and we would want these tools in there, especially with @zbyszek's recent changes to make it so %systemd_requires isn't used as much in our packages.

@ngompa I'm still failing to see your point here - with this PR both sysusers and tmpfiles could be installed within a container with only a dependency on libsystemd shared object, which is also split out into a subpackage.

For your container use-case, @filbranden's PR #27 is probably best suited, as it would allow installing sysusers and tmpfiles as self-contained packages without any shared object dependencies.

With this here, all packages requiring sysusers could now just add a Requires: systemd-sysusers, without declaring a dependency on the rest of systemd.

@lorbus #27 is unnecessary, generally speaking. I don't particularly care for statically linking libsystemd into tools. My point is that we're probably going to change things very soon to require and expect sysusers and tmpfiles to exist in all environments for packages...

@ngompa Regarding the tools with statically linked libsystemd, there's a significant total size difference and also dependency on other shared libraries that get pulled or not for the standalone binaries.

See for example:
https://github.com/systemd/systemd/pull/16061#issuecomment-641566933

Sorry for the delay. #25 and #34 are now merged. I think we should let the dust settle on those changes before doing further enhancements. So this PR might be still be relevant, but I'll return to it later.

So... is there something left to merge here? Or should we close this and pursue further changes in separate PRs?

Oh, this totally fell under table on my side (thanks for the reminder, Dusty!). Looks like this can be closed indeed.