On Mon, Apr 27, 2020 at 2:15 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Mon, Apr 27, 2020 at 01:19:29PM +0200, Petr Šabata wrote:
Based on the recent discussions around %fedora/%rhel macros and ELN, and %bcond generally being confusing to work with, I came up with a distribution-wide feature that defines generic feature keywords and associated helper macros that packages can check in build-time conditionals.
The key advantage here is the defaults are defined by the buildroot, not the package. The package is just a building block.
IMHO it is valuable having the package self-contained as it is today, as both maintainers & users are able to see and control exactly what features are intended, from a single place.
With this proposal they'd have to read the global.yml and the local.$PKG.yml and the $PKG.spec file to figure out what is going to be built. Some features will need to vary per-architecture too, so this will need a global-$ARCH.yml and a local-$ARCH.$PKG.yml file too for each Fedora arch, or the global.yml file will need to ship different content on each arch somehow. So that's potentially 3-5 files that need to be consulted to figure out what the enabled features are for a given package build.
Yes, there is this additional complexity of changing it / looking at two different places but that's the price paid for having the package itself independent and the features set by the environment. These approaches are not exclusive, people can use whichever method, although I obviously prefer the latter. Hence this proposal.
You're correct about the architecture-specific needs. I wanted to keep this simple and have people check for that in their packages. However, that might be contradicting the point above. Architecture-specific macros would solve this but be more complex to navigate and maintain.
I'd like some input to improve this and unless this turns out to be a really bad idea, I intend to submit it as a change proposal. Even though the more packages use it the more beneficial it gets, it's, of course, perfectly optional.
Details in the gist: https://gist.github.com/contyk/0aaaaf0585c57976ca18a293b3566408
IIUC, the global.yml file is intended to live in the use-macros package. It wasn't clear though where the local-$PKG.yml file is intended to live ? Is it for the use-macros too, or in the per-package dist-git ?
Both global and local macros live in the use-macros package. The YAMLs are sources and generate a single file with all the macros defined in it. Again, there's nothing binding the distribution local YAMLs to the packages themselves; they could be built in completely different buildroots with different macros set from exactly the same commit.
I'd be concerned about the per-package yml file living in "use-macros" because that would means when package maintainers need to rebase to a newer release, they potentially have to wait for any "use-macros" update to be approved & built before they can update their specfile in Fedora and do a build based on those features. This could also be an impact for users trying to build new upstream releases in Copr, if the features for the new upstream release ned to be different from those in the existing release for that Fedora release stream.
It's true this requires some coordination or uglier package checks (assume the originally submitted default value if undefined and simplify it later).
On the point about trying to maintain compat for existing distros which lack %use macros. I think the example shown is not the route I would take.
Instead I'd just define a %{with_XXX} macro for the feature upfront, based on the %{use XXX} macro value, and then not use the %use macros at all. In fact I might be inclined to do this even ignoring the old distro compat question, because it makes it easy to override the %{use} global defaults in the package.
%define with_foo %{?use:%{use foo}}%{!?use:1}
%if %{with_foo} BuildRequires: foo-devel
% define foo_configure_arg --with-foo % define foo_test_arg -Dfoo %endif
%prep %configure %{?foo_configure_arg}
%check make test %{?foo_test_arg}
You should also explicitly define --without-foo here. Sure, you could do it this way if you think it's nicer.
NB The "%{use_enable ...}" macro is targetting autoconf syntax, but autotools is not the only build system. Should this aim for a consistent approach - either provide macros for all build systems, or for none.
I started with these two helpers because autotools are extremely common and because the source of inspiration, Gentoo, also defines these. I have nothing against defining more for other build systems.
P