On Fri, May 10, 2019 at 08:21:24AM -0400, Neal Gompa wrote:
> On Thu, May 9, 2019 at 5:27 PM Zbigniew Jędrzejewski-Szmek
> <zbyszek@xxxxxxxxx> wrote:
> >
> > On Thu, May 09, 2019 at 04:56:25PM -0400, Neal Gompa wrote:
> > > On Thu, May 9, 2019 at 10:02 AM Zbigniew Jędrzejewski-Szmek
> > > <zbyszek@xxxxxxxxx> wrote:
> > > >
> > > > Hi,
> > > >
> > > > let's drop the requirement and ordering on systemd (as implemented by
> > > > %systemd_requires) from packages which provide systemd units.
> > > >
> > >
> > > In general, I think this idea has some solid foundation. But I think
> > > it'd be dangerous to remove any kind of ordering hints from the
> > > solution, because that means we'd need logic to handle system
> > > bootstrap that needs to include systemd in DNF
> >
> > What system bootstrap? Please explain.
> >
> > > Would transitioning from %{?systemd_requires} to %{?systemd_ordering}
> > > instead work to do what you want? That still offers the necessary
> > > ordering hints to ensure systemd is set up early in a large
> > > transaction that includes everything.
> >
> > If you are talking about an initial installation in the sense of
> > 'dnf --installroot=... install <long list of packages>', then it
> > shouldn't matter whether systemd is installed early or late. It is
> > not started in this transaction, and it should be totally OK (*) to install
> > it at very end.
> >
> > (*) As mentioned in my original e-mail, if packages have scriptlets
> > which use other systemd tools, this does not apply. But in that case those
> > packages need an explicit dependency.
> >
> > > I don't relish the potential bugs that would come from losing all of
> > > those hints in packages that we got from %{?systemd_requires}.
> > > However, %{?systemd_ordering} would fix that issue.
> >
> > No, neither should be needed.
> >
>
> systemd's preset functionality only kicks in when it installed and the
> preset files exist.
Yes.
> This means that for those scriptlets to actually work when systemd
> is requested, it needs to be early in the install order sequence.
No. (The scriplets themselves don't do anything, but equivalent effect
is provided by systemd package scriptlets which call preset-all.)
> I know that when using the systemd macros, they don't allow the
> package to fail if systemd isn't available. But I strongly disagree
> that allowing systemd to be installed more or less randomly is "fine"
> when making full system installs (such as through Anaconda net-install
> or dnf --installroot= install). With the way we call to systemd for
> presets, it makes much more sense to use %{?systemd_ordering} so that
> it works when systemd needs to be part of the system.
No.
> And the OrderWithRequires statement is supported in RHEL/CentOS 7, so
> %{?systemd_ordering} can be backported via the epel-rpm-macros package
> so that it works as intended.
Yes.
OK, I think I know where the misunderstanding lies.
You seem to assume that %systemd_ordering does something useful, i.e.
that it makes sense to install systemd early. It does not (*).
Please re-read my proposal, I think I explain pretty clearly why not.
Zbyszek
(*) As far as 'systemctl preset' is concerned. If the scriptlets call
other systemd tools, an ordering might still be needed.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
