On Mon, Apr 27, 2020 at 2:15 PM Daniel P. Berrangé <berrange(a)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