On Tue, Mar 04, 2025 at 02:00:23PM +0100, Adrian Schröter wrote:
On Dienstag, 4. März 2025, 13:38:09 CET Michal Suchánek wrote:
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: .... > > 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.
first of all, if you insist on package meta and links, you can still use them. Pointing links to any git managed source keeps working.
As long as you don't want to work on sources and merge them back you can work as before.
No I cannot. To have submittble package it cannot use links. That effectively bans links from develprojects.
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.
works as before. You can also use
%if "%_project" == "..."
in build config. That has the advantage it needs to be defined only once in a central place and you don't need to redefine it in each new project.
Why would I ever do that? The config is attached to a project, implicitly. If the config is inherited to a different project that builds against the project that has this config the conditional expansion is also inherited, and the setting is applied regardless of the project name. At least that's how it works for repository name conditionals.
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.
but these files have no meaning alone.
??? what else would you need? They refer to repositpry names, package names, and architectures which have meaning within the project they are attached to. Nothing else is required.
And you need to re-do it for every instance.
I need to do that every time I upload the kernel. At least with the meta files I start from clean slate, and do not have to examine parent projects, nor take into account inheritance between repositories. The result is clear and transparent, every time.
And you can not just copy them, but you need to adapt them.
I create them from scratch. Adapting (eg. changing repository name) is not all that difficult when parsers for the file format are ubiquitous.
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.
yes, and the only way out is to move the settings to the source. It can be in the package or project. build config is just one example.
What source? If you are talking about git repository that stores project state, and has the prjconf: Why it cannot have multiple files for specific purposes, and has to have one big, unintelligible mess of a file? I do not care where the prjmeta is stored so long as it is clear, intelligible, focused configuration file attached to the project. Actually to the repository, it looks to me like for projects that have multiple repositories project-global settings are the exception rather than the norm, and a lot of ifderery is used to apply per-repository settings in a per-project configuration. Thanks Michal