On Dienstag, 4. März 2025, 09:38:52 CET Michal Suchánek wrote:
On Tue, Mar 04, 2025 at 09:31:18AM +0100, Adrian Schröter wrote:
On Dienstag, 4. März 2025, 09:14:53 CET Richard Biener wrote:
On Mon, 3 Mar 2025, Michal Suchánek wrote:
On Mon, Mar 03, 2025 at 03:34:56PM +0100, Adrian Schröter wrote:
On Montag, 3. März 2025, 14:53:09 CET Michal Suchánek wrote:
On Mon, Mar 03, 2025 at 02:18:38PM +0100, Adrian Schröter wrote: > On Montag, 3. März 2025, 14:05:40 CET Michal Suchánek wrote:
... (trying to get back on focus)
> I agree, but this is actually the goal with git approach: > > Having one single identifier to get an entire build setup which can be used > to reproduce the entire build. This is not possible with classic OBS mechanics. > > Unfortunatly, this means that local hacks don't become easier ...
And hacks in prjconf suggested multiple times throughout this thread undermine this reproducibility, as is already the case with the old mechanic and multibuiltd.
I want: - everything built by default - a project configuration *DATA* file for selecting what to build, per architecture/repository/flavor
you can do this via the build config in a way that works in git projects and also in classic OBS setups (and solving issues there as well):
There are either onlybuild: or excludebuild: tags which you can use to enable or disable builds. You can use them also for flavors, for example
BuildFlags: excludebuild:<package>:<flavor>
like
BuildFlags: excludebuild:kernels-source:kernel-default
And you can have any %if statements (repository name, architecture, ..) around these.
This works with git and classic OBS, with project linking, via path elements and so on. And without the need to check at least 4 different source histories and replicating them just for a single build.
It actually does not.
1) this is inherited between repositories, and then once a build is disabled it cannot be reenabled
You can omit build config rules again on a higher level if needed via prefixing it with an !
For example
BuildFlags: !onlybuild:kernel-source:kernel-default
should enable it again, if it was disable in another repo you are referencing it.
Oh the atrocity intensifies. So if you want to build a package you have to negate any build flags that might have been set in a project you are building against.
How do you do that?
Set up the project, get the expanded prjconf, negate any flags present, and then add yours on top?
Could we just drop this atrocity in favor of actual data based per-repository configuration?
Actually, it should be easier because you could just build against the source and repositories of the base project. Atm. you have multiple revision repositories, in your case at least these: 1. Project meta repo 2. Project build config repo 3. kernel-source meta repo 4. kernel-source source repo 5. kernel-default meta repo 6. kernel-default source repo 7. kernel-obs-build meta repo 8. kernel-obs-build source repo 9. kernel-obs-qa meta repo 10. kernel-obs-qa source repo And for each kernel flavor you get two more. All of them are not connected and on a replication of the build setup you need to copy all of them and even worse, in package meta case there is code which needs to know which parts of the files can be copied, which needs to adapted and which must not be copied. In case you want to learn about the configuration of a build, you have to verify all of them independend. With the git approach there would be only 1. Project source, referencing to all package sources 2. Project meta repo (and even here we will be able to store critical parts in the source) And you don't need to fiddle around per package, they would get the config from the project source definition. Your branched project just needs to define the wanted repositories and these should have a path to their pendant of your base project. And you could even build entirely local and independend of any OBS instance using pbuild once we sync the project meta repository config with the project source store in git. IMHO it improves the situation a lot if we setup it correctly. -- Adrian Schroeter <adrian@suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev