On Tue, Mar 04, 2025 at 01:09:49PM +0100, 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.
How would you design this so the fiddling is not needed? The packages are built selectively in devel/test projects, and all in release project, by design.
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.
I cannot use it anymore because git workflow does not support package links, and package meta does not support multibuild. We do use multiple hacks that determine what to build out of the krenl sources based on the project name, and I would rather reduce them than add to them.
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?
Stuffing all settings for a lot of unrelated things into one file with unclear syntax that changes in the middle of the file is unintelligible. It might be possible to have a better structured prjconf that is actually intelligible but we don't have one. The prj meta and package meta are XML files that can be parsed with standard tools because they use standardized syntax. At most two apply to any given package. The settings describe boolean arrays that are multiplied to get the result. Compare that with prjconf that uses non-standard syntax for which there is no known parser library. It can have arbitrary depth. It is code with conditional statements, it cannot be merely parsed and extracted, it has to be interpreted. ExcludeBuild and OnlyBuild flags are not simple booleans, they have complex interaction. They cannot be used on their own, the project meta is still needed to set what architecture to build in which repository. Unfortunately there is overlap between prjconf and meta so you get arbitrary depth prjconf + 2 layers of mete. Yet to 'imrpove' you make meta that was predominantly used unusable so that the unconstrained depth prjconf must be used. The opposite would be desirable to make the configuration intelligible: less files involved, clearer syntax, bounded configuration complexity.
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.
The current direction makes it harder to reproduce and maintain so far.
All this is not used by at least 95% of package sources (or is it 99.9%?)
Execept 100% releases use some of these few % packages that are self-rerefencing - used to build themselves. So it's a case that's needed for every single medium built. Thanks Michal