Hi Andreas,
On Fri, 2025-03-07 at 16:02 +0100, Andreas Grünbacher wrote:
> Am Fr., 7. März 2025 um 15:57 Uhr schrieb Jean Delvare
> <[email protected]>:
> > Some build systems (such as OBS) don't work with compliant rpm spec
> > files. Instead, they use templates, which they preprocess before
> > passing them to rpmbuild. In order to be able to use "quilt setup"
> > on these spec files, we need to perform the same kind of
> > preprocessing.
>
> What kind of templates?
When I joined SUSE, most spec files did not use a real release number,
but a pseudo-release which abuild (and later OBS) was free to adjust:
Release: 141.<RELEASE156>
(The quilt package in openSUSE still has a custom patch applied to deal
with this. This never went upstream because it's hard-coded and ugly.)
Another frequent pattern these days is for multibuild packages
(packages which get built from the same sources multiple times with
different "flavors", and share a single spec file). These typically
start with:
%global flavor @BUILD_FLAVOR@%{nil}
and OBS replaces @BUILD_FLAVOR@ with an empty string for the main
package, and flavor strings for the flavored packages, before calling
rpmbuild.
There are also other cases where for example language-specific or
gnome-specific macros are called, and this fails locally unless some
devel package has been installed, but the outcome of the macros makes
no difference when only the %prep section of the spec file is
processed. So package maintainers prefer to skip the macro locally
instead of installing the devel package. This is less critical than the
two other cases, because a workaround exists, but once we have generic
mechanism in place, people will be free to filter out whatever macros
they want for free if it makes their lives easier.
> > For this purpose, introduce a new option to the setup command,
> > --spec-filter. This lets the user provide a customer filtering
> > script to preprocess their spec file before rpmbuild gets called on
> > it.
>
> Is there no way to detect and handle that kind of situation
> automatically, for example, if a spec file looks a certain way and a
> filter script with a particular name exists?
Hmm, that's an interesting idea, although this goes beyond the low
complexity I had in mind originally. Maybe this can be implemented
later, using some meta-data in the header comment of each filter?
Note though that the current implementation only allows for one filter,
so the first matching filter would be used. This could be a problem if
multiple filters share a given pattern.
My current idea in terms of making it as transparent as possible, was
to document on the SUSE side, that packagers should add this to their
~/.quiltrc:
QUILT_SETUP_ARGS="--spec-filter=obs"
So once configured, they no longer need to think about it.
--
Jean Delvare
SUSE L3 Support
_______________________________________________
Quilt-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/quilt-dev
