Mailinglist Archive: opensuse-buildservice (105 mails)

< Previous Next >
Re: [opensuse-buildservice] multibuild flavor vs package
Neal Gompa schrieb:
On Mon, Dec 9, 2019 at 7:21 AM Ludwig Nussel <ludwig.nussel@xxxxxxx> wrote:
Trying to figure out a way to use multibuild for mingw packages. The
challenge there is that almost all packages need to be built for 32bit
as well as 64bit Windows. So currently we have mingw32-foo and
mingw64-foo packages. With exactly identical spec files except for
s/mingw64/mingw32/ and vice versa. So sounds like a job for multibuild
with flavors mingw32 and mingw64 to produce those packages from a common
mingw-foo package.
Now there are also packages that have multiple spec files though like
gcc and pkgconf. Looks like that case was somehow forseen for multibuild
as there are 'flavor' and 'package' tags. In the end both are treated
the same though and end up as @BUILD_FLAVOR@ in spec files.

Are there any plans to change that? So one could write something like


to produce six packages?

Short of that would it work to have both links and multibuild? Ie links
according to spec file names and only mingw flavors?

Why not just define the flavors in the spec itself? It seems crazy to
try to use features like multibuild for this.

It's not difficult, see:

Alternatively, something like what we do for Python and Ruby builds
could do the trick here (macros that expand to flavors).

I am aware of those methods. Looks like it is a matter of choosing
your favorite way of getting tortured. The price of those is a lot
of (black) magic with macros. Tricky to implement and hard to debug.
Compared to that, multibuild looks rather straight forward to me.
That's why I'm exploring it first.

Requires some clarification of where multibuild leads to though.
Dominique also filed an issue for that:

When thinking about it I wonder if a _multibuild file is needed at
all. The spec file selection could be solved with classical
links just fine. Maybe with some more code in OBS to create the
requires packages automatically on request accept, like external
scripts do (or did?) for staging.

The flavors with the @BUILD_FLAVOR@ substitution feels like it
should be done in a more rpmish way.

Thinking of extending bcond, eg assuming we have

%bcond_with bootstrap
%bcond_with small
%bcond_with full
%if %{with bootstrap}

One could come up with a macro to replace the %bcond_with lines,
let's say

%{bcond_xor bootstrap small full}

So that bcond_xor would have to make sure one of the options is
actually selected and fail rpmbuild if not.

OBS would then have to parse the %bcond_xor macro in the spec to
generate those virtual packages with colon separated flavor we know
from multibuild today.


(o_ Ludwig Nussel
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups