https://bugzilla.redhat.com/show_bug.cgi?id=1118740 --- Comment #21 from Harald Hoyer <harald@xxxxxxxxxx> --- (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 _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/package-review@xxxxxxxxxxxxxxxxxxxxxxx