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? Thanks Michal