On Thu, 27 Feb 2025, Richard Biener wrote:
On Thu, 27 Feb 2025, Adrian Schröter wrote:
On Donnerstag, 27. Februar 2025, 12:24:26 CET Dominique Leuenberger wrote:
On Thu, 2025-02-27 at 12:21 +0100, Adam Majer wrote:
On 2/27/25 11:05, Jiri Slaby wrote:
On a similar note: where is package meta for scmsync _projects_? Use case: Disable building some packages on some repositories. I.e. where to put: <build> <disable repository="15.6"/> <disable repository="Fedora_40"/> </build> ?
It will be part of the project meta BuildFlags.
https://src.opensuse.org/cockpit/_ObsPrj/src/branch/master/_config
BuildFlags: excludebuild:cockpit-suse-theme
%if "%_repository" == "openSUSE_Factory_ARM" || "%_repository" == "openSUSE_Tumbleweed"
BuildFlags: excludebuild:local-npm-registry %endif
Is way to disable builds now.
https://openbuildservice.org/help/manuals/obs-user-guide/cha-obs-prjconfig#s...
excluding builds and disabling builds is by far not the same (excludebuild wipes binaries for example, disable keeps them)
What about the rest of package meta, like useforbuild?
In general the goal is to obsolete the parallel meta information with the project git and having everything what we need in the sources.
Either package sources or additional configuration files in the project.
Build flags were often a problem since they could not be transfered into other projects as things like repository names did change. Also problems with old build results lead to issues where content is not rebuildable. So our vision so far is to obsolete them and try to stick to the exclude mechanic only. This can be specified in the package source already (eg. ExcludeArch in spec files or special tags in Dockerfile or kiwi files).
We have no replacement for useforbuild yet. It could be added, but do we have really a usecase for it? In the past it caused mostly trouble. It is easy to add, if there is a usecase.
Yes, useforbuild setting is critical for devel:gcc.
Also note that while some build enable/disable is source specific in many cases (devel:gcc!) it's specific to the repository we build against! So IMO there needs to be a way to amend/override settings in the OBS build project, having this only as part of the source is not enough (in fact it's wrong). And I agree, having it as part of the project config (which also has its build and its source part!) is just wrong.
So after pondering a bit on how migration could work for devel:gcc with some of the OBS features (temporarily) gone I think the solution is likely to split up devel:gcc on the OBS side and have devel:gcc itself only build oS:Factory repositories (where useforbuild is generally enabled and wanted) and have repositories for SLES and Leap be built in one (or many) separate OBS projects that can then disable useforbuild project-wide and possibly pick packages from src.o.o on a package-by-package basis (or have a filtering import, for example to exclude 'gcc' from building in these OBS projects). The reason this is now all in devel:gcc is because sources are in OBS and it's how most other devel projects handled this. Thus - moving sources to src.o.o is the opportunity to re-think the layout of OBS build projects when it comes to building packages for SLES and Leap (as "backports"). Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)