|
Bugzilla – Full Text Bug Listing |
| Summary: | cannot specify which multibuild package flavors to build in package metadata | ||
|---|---|---|---|
| Product: | [Internal Novell Products] openSUSE Build Service | Reporter: | Michal Suchanek <msuchanek> |
| Component: | backend | Assignee: | Michael Schröder <mls> |
| Status: | NEW --- | QA Contact: | Adrian Schröter <adrian.schroeter> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | ivan.ivanov |
| Version: | master | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Bug Depends on: | |||
| Bug Blocks: | 1211226, 1218184 | ||
|
Description
Michal Suchanek
2024-01-19 14:04:56 UTC
IMHO the approach in setting this via repository names is kind of flawed. In ALP we maintain sources in dependend of the projects which may build it. And these projects are free to setup and name their repositories as they want. Did you discuss just to use the rpm with/without mechanics and set the defaults in prjconf based on the repository name? That way a forked project, when building based on your your repository setup, would still get these settings. And other products, which re-setup a kernel build from scratch would need to take care to take care on their own, but templates could help there. We set this by hacks in rpm using repository names because the mechanism to set this on OBS is not provided anymore. With package links the repository to build in was set in OBS package metadata and the rpm did not have any knowledge of that, the separation of duties between rpm(sources) and OBS(build settings) worked correctly. That's no longer possible with multibuild, and that's the reason why knowledge of repository names bleeds into rpm spec files. Also 'set defaults in prjconf' how, specifically? The documented way to set in which repository to build and for which we have UI are the build flags in project and package metadata, these are not provided for multibuild flavors. Please go away from the meta data, we won't support this in future anymore. Also the UI will not be able to modify this data anymore when your project got switched to git.
I had the something like the following in mind:
%if "%_repository" = "QA"
Macros:
%enable_qa 1
:Macros
%endif
and inside the spec file something like
%if 0%{?enable_qa}
...
%endif
We currently have:
Macros:
%is_kotd 1
%klp_symbols 1
%is_kotd_qa (("%_repository" == "QA") || ("%_repository" == "QA_ARM") || ("%_repository" == "QA_LEGACYX86") || ("%_repository" == "QA_PPC") || ("%_repository" == "QA_RISCV") || ("%_repository" == "QA_S390"))
:Macros
because of course, the way to do conditionals in prjconf is not documented.
In any case, for the user to be able to set this macro they need to read the spec file, notice that a macro is_kotd_qa that is never set (neither in the package not distro-shipped rpm macros, eh) is checked, and set it in the prjconf. That's frankly not something I would expect even an above-average user to be able to do.
Any such bodge is package-specific, with no general OBS-wide documentation, and has no UI.
I suppose %bcond would be a good candidate - it makes it possible to clarify that this is a build configuration input that the user can set, and the backend could get the list of %bcond settings for the UI to render somewhere. Unfortunately, this is available only since rpm 4.17.1, previous versions only have the backwards %bcond_with X that disables X, and %bcond_without X that enables X. you can combine this when you have something like
%if 0%{?enable_qa}
%becond_without
%else
%bcond_with ..
%endif
in your spec file.
Regarding documentation, this is in first place rpm syntax, so rpm documentation is mainly responsible. But we should have the OBS specifics in
https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.prjconfig#sec.prjconfig.about
I will extend that one with the default macros like %_repository
(In reply to Adrian Schröter from comment #7) > you can combine this when you have something like > > %if 0%{?enable_qa} > %becond_without > %else > %bcond_with .. > %endif It only helps if OBS itself sets the conditionals, and if it's possible to do without the backwards _with and _without suffixes. Here what the prjconf sets is random package-specific macro, the %bcond is redundant there. > Regarding documentation, this is in first place rpm syntax, so rpm > documentation is mainly responsible. But we should have the OBS specifics in OBS could use that rpm syntax to present the options to set to the user in the UI, then it becomes part of the OBS. Otherwise, %bcond is not particularly useful on its own, especially in the old backwards syntax. > > https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs. > prjconfig#sec.prjconfig.about > > I will extend that one with the default macros like %_repository It does not say anything about conditionals either, sadly. And here the conditionals are 100% OBS syntax, in the macro section that is rpm macro file syntax they are not supported. |