https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Harald Hoyer <harald(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |harald(a)redhat.com
--- Comment #20 from Harald Hoyer <harald(a)redhat.com> ---
(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.
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