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.
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).
Cheers,
Björn
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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
