Re: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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. This means that for those scriptlets to actually
work when systemd is requested, it needs to be early in the install
order sequence.

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.

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.


-- 
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux