On Thu, May 09, 2019 at 07:56:22PM +0200, Björn 'besser82' Esser wrote:
> Am Donnerstag, den 09.05.2019, 10:21 -0700 schrieb Japheth Cleaver:
> > On 5/9/2019 7:46 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Thu, May 09, 2019 at 09:19:32AM -0500, Mátyás Selmeci wrote:
> > > > On 5/9/19 9:00 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > > > Hi,
> > > > >
> > > > > let's drop the requirement and ordering on systemd (as
> > > > > implemented by
> > > > > %systemd_requires) from packages which provide systemd units.
> > > > >
> > > > > I now filed [1], which removes the recommendation to use
> > > > > %systemd_requires.
> > > > > Quoting from that ticket:
> > > > >
> > > > > Nowadays systemd.rpm does a preset-all call when it is
> > > > > installed.
> > > > > This means that individual packages which provide systemd
> > > > > units and
> > > > > call %systemd_post in their %post will work fine no matter
> > > > > if they
> > > > > are installed *before* or *after* systemd.
> > > >
> > > > Is this true for the version of systemd in RHEL 7 and compatible
> > > > as well?
> > > > How will this affect EPEL packages?
> > > systemd in RHEL generally follows the changes in Fedora, with a
> > > delay.
> > > If this is changed in F31, then it wouldn't filter down to RHEL
> > > until
> > > the next RHEL release. Similarly, such changes should not be
> > > propagated to
> > > packages in EPEL7.
> > >
> > > Zbyszek
> >
> > RHEL8 has been out for all of two days. EPEL8 is still to come.
> >
> > So long as EPEL (and Rawhide, tbh) are under the aegis of Fedora, it
> > would be nice at least /some/ effort was made not to toss over
> > incompatible changes, or a broad need for dist conditionals, across
> > the
> > package ecosystem with such cavilerity.
> >
> > -jc
>
>
> The impact of this change is not too bad considering a few things:
>
> The use of the `%systemd_requires` macros must be changed to
> `%{?systemd_requires}` in each spec file. That way rpmbuild will
> evaluate whether the macro is defined and after that will fill in the
> body of the macro. If it is not defined rpmbuild will simply replace
> the `%{?systemd_requires}` with %nil.
My idea was to keep %systemd_requires defined, but to simply remove
its use from packages in the master branches. I think that's preferable
because it makes the transition smoother: existing packages keep
working, and the dependency can be removed one-by-one without any
flag day. If some packages are not changed, there's no issue apart
from an extra dep.
OTOH, if we stopped defining %systemd_requires, it'd be necessary to
go over all packages and make sure that they don't need the dependency
for some other reason, and if they do, add the dependency in a different
form, so that it still declared when %systemd_requires go away. This
seems like more churn and more chance for breakage.
> That way the definition of that macro can be fully dropped from F-31+
> (and thus get reintroduced at any time later, if needed for $reasons),
> while still keeping the spec file fully compatible with any prior
> releases (including EPEL / RHEL).
I don't think that's worth the trouble. As stated elsewhere in the thread,
we have branches for this. And even if one wants to keep the branches
the same, either conditionalizing or even keeping the extra dep are
perfectly viable options.
Zbyszek
_______________________________________________
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
