On Freitag, 10. Mai 2019, 22:22:51 CEST Jimmy Berry wrote:
To make this even further convoluted /search/package[/id] appears to have enough information to filter client-side. The output contains <releasename> when it is a maintenance update
yes
and <bcntsynctag> when it is a multi-spec package.
but also in other cases.
Unfortunately, the search route does not include inherited packages while the /source route does with ?view=info. Although the source route expands things are not sources (_multibuild psuedo packages) while search contains neither.
A side topic is the multispec implementation of a package that links to another within same project makes for fun stuff like this:
osc api '/search/package/id?match=@project="openSUSE:Factory"+and+devel/ @project=@project'
<collection matches="334"> <package project='openSUSE:Factory' name='FreeCAD-test'/> <package project='openSUSE:Factory' name='Mesa-drivers'/> <package project='openSUSE:Factory' name='NetworkManager-branding-SLE'/> ... </collection>
If one writes a tool, like repo-checker, which wants to notify maintainers about a problem with a specific binary it asks OBS what package the binary came from and if one of the above 334 packages gets the multi-spec implementation detail package and looks up the devel maintainer which is Factory not the real one which would requiring following the multi-spec link to _real_ source package and then following that back to devel project.
The fact that these implementation details are exposed at all and worse inconsistently like they are makes writing tools almost impossible. Merging multi-spec into _multibuild so that they can optionally be handled the same way (generate psuedo packages with : in name) instead of linked container (while still supporting old style) would make this at least one step better.
first of all, _multibuild and multiple spec files via source links are two independend concepts. They can be even combined, only a factory policy forbids this atm. _multibuild is a definition inside of the source, while the package links are a decision on the project level.
Then one can determine multibuild packages using : in name since reserved character and cases like repo-checker work as expected. It's also logicaly what you expect, I have two builds of Mesa: one for X and one for Y. I do not have Mesa and Mesa-drivers.
Handling this via multibuild should be fairly simple:
_multibuild: mesa, mesa-drivers mesa.spec mesa-drivers.spec
if exists(multibuild_name + '.spec'): run that spec the same way multi-spec did else: current _multibuild behavior (variable to single spec)
Still not a solution for the immediate problem of knowing the "kind" of package since the tooling will need to work for existing products even if this is cleaned up.
We could indeed support specific build description files in _multibuild, just we need to make this most likely an explicit setting inside of the _multibuild xml. However, back to the original problem. Multibuild ========== My question regarding the purpose was because I think that you don't need to have this logic outside of OBS. It is even harmfull when we enhance our mechanics more (eg. further multibuild features), because it will break this logic again. Eg. instead of delivering specific search calls, we should do support instead osc branch $project $package:$multibuild_flavor or URLs like https://build.opensuse.org/package..../$package:$multibuild_flavor so it does not matter that you get the mutibuild source containers. This is why I keep asking what you want to do with that information... Local Links =========== Same regarding the project local links, you should be fine if all packages get the devel definition back. Meaning that in the package meta of Mesa- drivers you add again <devel package="Mesa"/> so operations like branch calls get automatically redirected to the right place. Yes, this is manual work here, but this is basically the main difference between _multibuild and local links. Maintenance Release Projects ============================ Last, we can indeed support some simplified listings for maintenance_release projects. We will need an extra option, but shouldn't be too complicate. Does this sound like a plan? -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org