[Bug 1219005] New: cannot specify which multibuild package flavors to build in package metadata
https://bugzilla.suse.com/show_bug.cgi?id=1219005 Bug ID: 1219005 Summary: cannot specify which multibuild package flavors to build in package metadata Classification: Internal Novell Products Product: openSUSE Build Service Version: master Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: backend Assignee: mls@suse.com Reporter: msuchanek@suse.com QA Contact: adrian.schroeter@suse.com Target Milestone: --- Found By: --- Blocker: --- For some packages a number of different builds uses the same source. For consistency and efficiency it is required to upload the sources only once, and run multiple builds against the same sources. Historically this has been done by package links: The sources would be uploaded with a number of spec files, and a number of package links created. Because OBS selects the spec file to build based on container name the different package links would build different spec files. In other ways these package links appear as any other build containers. In particular, it's possible to select in what repositories (if any) the individual spec files should be built in the package container metadata. There is a push to convert these packages to use multibuild instead. With multibuild a _multibuild file is created that lists the spec files to build but only one package container is created in which all these spec files are built. That results in only one container metadata, and inability to specify which spec file to build in which repository. https://github.com/openSUSE/open-build-service/issues/3574 This is important functionality for package development. The kernel uses this functionality to set up multiple repositories in the development project and select which spec file to build in which repository. That makes it possible to test kernel builds without breaking the project when the kernel fails to boot on the OBS builder. For both kernel and other packages that build a number of configurations this is important for people that want to branch the package and only build/change a specific configuration. Currently kernel and u-boot use different hacks to workaround this deficiency in OBS multibuild support, some packages completely give up on controlling which individual configurations to build. That means users that branch these multibuild packages have to read the package sources to find out how to select which configuration to build if the option is provided at all. There is no standardized and documented way to do it. Some workarounds have been proposed. The obvious one is to change the _multibuild file but that results in changing the package sources, it becomes a different package then. All already built configurations are rebuilt after the change. The source change is likely to cause package breaks because OBS is very bad at resolving updates to modified packages. Another option are build flags in project config. onlybuild/excludebuild flags can be used to (de)select some configurations. However, the project config is inherited, and so are these flags. Building against a project that already (de)selected some configuration (de)selects same configurations for the branched package, and this cannot be changed. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219005 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1218184, 1211226 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219005 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1219011 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219005 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|1219011 | -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219005 Ivan Ivanov <ivan.ivanov@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ivan.ivanov@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219005 https://bugzilla.suse.com/show_bug.cgi?id=1219005#c1 --- Comment #1 from Adrian Schröter <adrian.schroeter@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219005 https://bugzilla.suse.com/show_bug.cgi?id=1219005#c2 --- Comment #2 from Michal Suchanek <msuchanek@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219005 https://bugzilla.suse.com/show_bug.cgi?id=1219005#c3 --- Comment #3 from Michal Suchanek <msuchanek@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219005 https://bugzilla.suse.com/show_bug.cgi?id=1219005#c4 --- Comment #4 from Adrian Schröter <adrian.schroeter@suse.com> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219005 https://bugzilla.suse.com/show_bug.cgi?id=1219005#c5 --- Comment #5 from Michal Suchanek <msuchanek@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219005 https://bugzilla.suse.com/show_bug.cgi?id=1219005#c6 --- Comment #6 from Michal Suchanek <msuchanek@suse.com> --- 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 are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219005 https://bugzilla.suse.com/show_bug.cgi?id=1219005#c7 --- Comment #7 from Adrian Schröter <adrian.schroeter@suse.com> --- 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#s... I will extend that one with the default macros like %_repository -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219005 https://bugzilla.suse.com/show_bug.cgi?id=1219005#c8 --- Comment #8 from Michal Suchanek <msuchanek@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219005 Gustavo Yokoyama Ribeiro <gyribeiro@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|1218184 | -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com