On Wed, Aug 05, 2020 at 12:52:15PM +0200, Andrea Bolognani wrote: > On Wed, 2020-08-05 at 12:24 +0200, Pavel Hrdina wrote: > > On Wed, Aug 05, 2020 at 11:52:30AM +0200, Andrea Bolognani wrote: > > > Oh, I see now the %meson macro is shipped as part of meson itself. We > > > definitely don't want to install two versions of meson, and if we end > > > up agreeing that keeping RPM builds working on CentOS is important we > > > will have to work around the need for the macro on CentOS 7 anyway, > > > so we should be able to use that same workaround on CentOS 8 too. > > > > We need to figure it out somehow but I'm not sure that we want to copy > > the content of /usr/lib/rpm/macros.d/macros.meson file into our spec > > file. > > > > Downstream maintainers will probably have to bundle meson 0.54.0 > > together with libvirt in the packages, that was my original motivation > > not to introduce the BuildRequires in our spec file. It was pointed out > > during review that I should add it there, which actually makes sense as > > we depend on the macro. > > > > For our testing purposes we can install the system wide meson and newer > > version from PyPi if required and remove the version requirement from > > the spec file. > > > > That way downstream maintainers will get the system wide meson with > > meson macros for RPM and if required they will use the bundled meson to > > do the compilation. > > > > Everything should work and we will not make our spec file even more > > complex. > > So you're suggesting that on CentOS we install Meson both from RPM > and from PyPi, the former being used only for the RPM macros? I don't > think that's a good approach; in addition, that's not something that > we can accomodate in our CI pipeline without gross hacks. > > Including the RPM macros directly in our spec file, conditionally and > only for CentOS of course, doesn't seem too bad: that's just 45 lines > of code, which is basically a drop in the ocean considering that our > spec file is almost 2000 lines long. > > We could make the BuildRequires conditional in the same way. Gross hack in our CI vs gross hack in spec file. I vote for CI to have the hack. In addition the macros are provided by meson and there are changes in the macro file, for example the latest macro file uses `meson compile` instead of `ninja build` which was introduced in 0.54.0 so we would have to have some older copy of the macros. We could probably come up with some replacement for the macro that would work on all OSes that lack the correct meson version but I don't think it's better then having it solved in our CI. And the fact that our spec file is already large is not a solid argument to add some ugly workaround there. If anything we should clean it up. Pavel
Attachment:
signature.asc
Description: PGP signature
