debian: replace @BUILD_FLAVOR@ in parse and dsc source preparation

[rjd15372]

This commit improves the support for multibuild when building debian-based packages.

• The @BUILD_FLAVOR@ can now be used in the .dsc or debian.control file to correctly identify build dependencies.

• The @BUILD_FLAVOR@ can also be used debian/control and debian/rules files, which are processed during build time but before the debian packaging process starts

[darix]

at least in the rpm space empty flavor is actually valid. see e.g.:

https://build.opensuse.org/package/show/server:database:postgresql/pgrx

for other packages where we have nothing to build in an empty flavor we use the do_not_build hack

https://build.opensuse.org/package/show/server:database:postgresql/VectorChord

my suggestion in a meeting earlier was that we had something like

<multibuild buildemptyflavor="false">
  <package>postgresql14</package>
  <package>postgresql15</package>
  <package>postgresql16</package>
  <package>postgresql17</package>
  <package>postgresql18</package>
</multibuild>

[rjd15372]

@darix how can we implement a similar hack for debian packages? Is this something that is built in obs-build, or in open-build-service?

[darix]

my suggestion is that "emptybuildflavor" attribute :)

well as we can see with the pgrx example. we would also need conditionals build requires in that case and currently we have no native conditionals support in within the dsc files.

I wonder if we should do pkgname.flavor.dsc ?

[rjd15372]

my suggestion is that "emptybuildflavor" attribute :)

well as we can see with the pgrx example. we would also need conditionals build requires in that case and currently we have no native conditionals support in within the dsc files.

I wonder if we should do pkgname.flavor.dsc ?

I just don't like the pkgname.flavor.dsc approach because then we would need to have a .dsc per flavor, with probably the same content.

In my little experience, I think we just need two .dsc files, one for the non-multibuild or empty-flavor case, and another for the multibuild flavor case.

Another approach could be to have a bash script file deb.multibuild.sh, that if present, is called by obs-build to rewrite the recipe file. We expose the buildflavor value as an env var to the bash script, and the script modifies the recipe file, which filepath is also passed as an env var to the script. If the script is not present, we fallback to the behavior that is implemented in this PR and respecting the emptybuildflavor attribute.

[rjd15372]

I'll open a new PR with just the emptybuildflavor attribute implementation.

[rjd15372]

@darix I've implemented the buildemptyflavor attribute feature in:

openSUSE/open-build-service#19319
and
#1124