On Thu, May 9, 2019 at 1:57 PM Björn 'besser82' Esser
<besser82@xxxxxxxxxxxxxxxxx> 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.
>
> 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
RHEL or EPEL compatibility will definitely require other factors, for
RHEL 6 and 7 as well as RHEL 8. The "with_python3" options will
require parallel "with_python2" options for compatibility with RHEL 6,
and ideally disable with_python2 for Fedora 30 and 31, even if they
were simply discarded as compilation for Fedora 30. "Suggests:"
options for dnf will need to be enabled for RHEL 8, but not older
versions of RHEL. I've found it useful to compile such packages with
mock for RHEL 7 and the current Fedora to verify compatibility. The
python tests, in particular, may not have occurred with the other
version of python. (I just ran into this with python3 and subversion.)
And do not get me *going* on RHEL 8's decision to split its
installation media to have two different dnf repositories on the same
installation disk, one in a subdirectory called "BaseOS" and another
called "Appstream" for no reason I can figure out. It means yum repos
or mock setups from the DVD image need to list both repositories
distinctly, for no reason I can imagine.
_______________________________________________
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
