https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #21 from Harald Hoyer harald@redhat.com --- (In reply to Harald Hoyer from comment #20)
(In reply to Yaakov Selkowitz from comment #19)
(In reply to Zbigniew Jędrzejewski-Szmek from comment #17)
Afaik, this package was causing more problems then it was solving, and that's why it was never built and submitted as an update. If that is true, it would be best to clearly kill the package (make it a dead package).
Could you specify? I believe this would still be useful as systemd and its dependencies still take up a lot of space (~16%) in a docker base image for seemingly no reason.
As for how to handle the Conflicts, I think we can use coreutils-single as a model. Based on that, systemd should:
Conflicts: fakesystemd Obsoletes: fakesystemd
and then fakesystemd should:
Provides: systemd
If that is done, does that solve whatever problems there were?
I would rather go down the road and create an opt-in scheme, where packages remove the %systemd_requires macro, if the package is able to run without systemd.
Requires(post): systemd Requires(preun): systemd Requires(postun): systemd
would become
Recommends: systemd OrderWithRequires(post): systemd OrderWithRequires(preun): systemd OrderWithRequires(postun): systemd
The systemd_{post,preun} macros don't fail, if anything goes wrong.
E.g. packages, which rely on %sysusers_create would probably not work.
Or if packages rely on a systemd API/ABI/functionality.
Please let it be an opt-in, rather than a magic fakesystemd package, where support tickets will be opened, because the package doesn't work as advertised, because it really needs a functional systemd.