On Tue, 4 Mar 2025, Adrian Schröter wrote:
On Dienstag, 4. März 2025, 12:43:57 CET Michal Suchánek wrote:
On Tue, Mar 04, 2025 at 12:28:27PM +0100, Adrian Schröter wrote:
On Dienstag, 4. März 2025, 11:57:57 CET Michal Suchánek wrote:
On Tue, Mar 04, 2025 at 11:41:58AM +0100, Adrian Schröter wrote:
On Dienstag, 4. März 2025, 11:35:27 CET Michal Suchánek wrote:
On Tue, Mar 04, 2025 at 11:27:12AM +0100, Adrian Schröter wrote: > On Dienstag, 4. März 2025, 09:58:13 CET Michal Suchánek wrote: > > On Tue, Mar 04, 2025 at 09:49:58AM +0100, Adrian Schröter wrote: > > > 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. > > > > It utterly fails when I want to build the package independetly of the > > base project build settings because these are silently imported, the > > format of the settings is unspecified, > > what do you mean here exactly? The BuildFlags are specified in > > https://opensuse.github.io/obs-build/pbuild.html#_about_the_build_configurat... > > . IMHO as good documented as any package meta flag.
Yes, the flags are. The file as a whole is not.
The syntax of the conditionals is not defined.
indeed, we can add that.
The syntax is whatever rpm accepts, and rpm syntax is not documented, either. So no, you cannot unless you take on documenting rpm spec and macro file syntax, and then define which is used in which parts of the prjconf.
we don't use rpm to interpret this file to schedule build jobs. We know our parser, so we can document it.
The inheritance is poorly documented.
that is independ an obs feature.
And previously was not involved in setting what to build, and now is.
That's one of the problems. It's no longer an independent OBS feature.
??? any package meta setting was always only an OBS feature.
There is now the additional possibility to build also independ of OBS.
But we build also the same inside of OBS.
The prjconf is inherited between projects.
The build flags that determine what to build are now in projconf.
That makes prjconf now releavant to what ends up getting built.
And I have to wonder how these same flags now get anywhere indeoendent of OBS. That's just not possible. You absolutely have to ask OBS what the final flags aggregated from your project and all upstream project will be.
IMHO it helps a lot when these config settings get re-applied by default in your branched project. Also in your special case. You don't need manual to fiddle around with flag settings in each package meta, if the design is right.
That setting these buildflags requires examining buildflags of all projects built against is definitely not explicitly documented.
that is in general true for any build config setting which is there in OBS.
Indeed. Except the old build selection settings were not in prjconf, they were separate.
They could be randomly copied when packages were branched but then were separate and explicit. The whole settings would be visible as a XML document in the project they apply to, and could be altered in the web UI as well as by editing that one project.
you obviously never had to debug a state, not understandable by someone, where you had to check several meta histories, sync timestamps between them, guess temporary build states at that time and that via many repositories and projects.
That's exactly what prjconf leads to, and configuration independent of prjconf, specific to one project, without inheritance can avoid.
I don't insist on build config, we can also think about hints in the package source. Just the package meta itself is not acceptable. Well, except you say it is anywany only your personal pet project, not planned to be merged. There you can still use it as before and just reference to the git repo per package manually, if you want.
The less stuff in prjconf the easier debugging. Yet you want to 'improve' OBS by stuffing more into already unintelligible and unamaintainable prjconf files.
IMHO distributing settings to multiple places is neither intelligible and maintainable. What should be the reson that 3 config settings out of a large set should be configured different? But everything else is still build config?
Please also consider usability by people who do not spend their days by staring ar OBS code.
Well, we speak here about a very special exception setup. Something were you already use a setup what needs a lot of internal OBS knowledge in error case.
And even here I think we could make it more reproducible and easy to maintain then before.
All this is not used by at least 95% of package sources (or is it 99.9%?)
It sounds like the main point about this is that there's "source" besides the source of packages. Namely there's "source" for an integration project like openSUSE:Factory - it's project config. But there's also "source" (or config) for a specific build, like for devel:gcc or for the Kernel projects. But I do _not_ see any part of the current project config as essential part of a _package_ source. IMO it's desirable to separate those two aspects clearly. For example the project config parts of packages tracked in devel project "X" should then literally be intergrated into the project config of the aggregator (openSUSE:Factory for example). But what if the same packages should also go to SLE15? It's ofthen the case (well, speaking for GCC ...) that the project config details for the aggregating project (SLE15 vs. openSUSE:Factory) are different, so a single project config in the git sources of the "devel" project isn't sufficient. So we'd need a devel-X-for-SLE15 git project that aggregates the package sources but has a separate project config in git? And if I want a special bootstrap OBS project then I of course want to have a project config (override) just there. I think I understood I can do that, even with package meta, if I avoid doing a project-wide scmlink but instead do per-package scmlinks. 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)