https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #21 from Harald Hoyer <harald(a)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.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component