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:
On Mon, Mar 03, 2025 at 01:56:18PM +0100, Michal Suchánek wrote:
On Mon, Mar 03, 2025 at 01:41:53PM +0100, Adrian Schröter wrote:
On Montag, 3. März 2025, 13:01:53 CET Michal Suchánek wrote:
On Mon, Mar 03, 2025 at 12:52:26PM +0100, Michal Suchánek wrote:
On Mon, Mar 03, 2025 at 12:44:41PM +0100, Adrian Schröter wrote: > On Montag, 3. März 2025, 11:52:45 CET Michal Suchánek wrote: > > On Fri, Feb 28, 2025 at 08:54:49AM +0100, Adrian Schröter wrote: > > > On Freitag, 28. Februar 2025, 07:17:21 CET Jiri Slaby wrote: > > > > On 27. 02. 25, 14:10, Adrian Schröter wrote: > > > > > On Donnerstag, 27. Februar 2025, 12:56:36 CET Jiri Slaby wrote: > > > > >> On 25. 02. 25, 17:19, Adam Majer wrote: > > > > >>> For information of what is happening, etc. please see, > > > > >>> > > > > >>> https://en.opensuse.org/openSUSE:OBS_to_Git > > > > >> > > > > >> I see Kernel:stable in the list of planned to be migrated. However our > > > > >> kernel still uses _link. So who is going to fix this before the > > > > >> beginning of Apr ;): > > > > >> https://bugzilla.suse.com/show_bug.cgi?id=1211226 > > > > >> ? > > > > > > > > > > You are using local links only. That works via a symlink in the project git. > > > > > > > > I realized we actually use multibuild already, but the bug remains -- > > > > it's impossible ATM to exclude the build properly with multibuild (see > > > > the bug). > > > > > > It is possible via project config, basically excluding the flavors you > > > don't wont via BuildFlags: excludebuild: > > > > > > An alternative would be an extension to the scmsync handling that you > > > could extend the git sync url with eg > > > > > > ?onlyflavor=kernel-default&onlyflavor=kernel-source > > > > > > to limit the flavors. We could implement that if someone opens a feature request > > > in the obs-scm-bridge github component :) > > > > As has been discussed in the bug this does not work because the prjconf > > and with it these enable/disable flags are inherited by projects that > > build against it. That makes it impossible to re-enable something once > > disabled. > > The suggested onlyflavor cgi parameter would be only used in your own > project/package meta data. > > eg. you create in your home project a package meta with > > ... > <scmsync>https://src.opensuse.org/pool/kernel-source?onlyflavor=kernel-source&onlyflavor=kernel-default</scmsync> > ... > > And it would only trigger these two flavors independend of any base > project or package source. > > (again, this is not yet implemented, but we could if wanted)
How does that work for multiple repositories and architectures in the project?
This implies that you create a obs package meta with this element.
You can use any classic flags in the package meta there. Also any repository configuration in your local project meta.
If you want to have different flavors extract by arch and/or repository name you would need to create a second package meta which could point to the same git repository.
So one package for each flavor/repository combination to build, with no way to override the settings in the UI?
It is an option, if you need to override per package build defaults which are otherwise defined in the project.
Does not sound like a good setup.
I agree, but I think the problem lies deeper here. Exceptions of build behaviour per package were always be a problem. It also breaks in old mechanics when you use eg. project links or trying to reproduce the result in another OBS instance.
And because build results from such multitude of packages linked to the same git sources are not linked together when submitting from such develproject the build result will not get checnked.
inside of a devel project such hacks should never be needed. They never could be submitted to factory in the past. No there would be mechanics to transfer flags because they become part of the sources.
They are needed - for aggregating per-architecture builds against different projects - for breaking the self-reference of package that is used to build itself Neither is needed in Factory but both are needed in the develproject to continuously provide build results as the package is updated.
And how it works for package links?
in general, you can link _to_ any scmsync package object. But you can not use _link's inside of git sources. However, the obvious way out here is just to point to the same git repo.
Which does not work for adding modifications in the link.
We need to distinguish between official projects, like openSUSE:* and devel projects where we have git projects.
But for any personal setups like mentioned here you can still manual setup classic OBS projects and use mechanics link _link even including auto merging code.
But not for setting what to build.
I suppose branching packages would be done in git when the project is git-based so this would be non-issue for the common case.
yes. (even though we call it fork'ing in our terminology, since branching means something different in OBS and also in git world).
However, it has been pointed out that some features of package linking will be still provided only by .. package linking, and in that case the build settings youls be inherited through the link, again with no way to override.
as long as you don't need it in official projects, you can still use that.
Nope. The features are provided by different mutually incompatible mechanisms. So while the features exist in isolation they cannot be used together.
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 Thanks Michal