Mailinglist Archive: opensuse-buildservice (74 mails)

< Previous Next >
Re: [opensuse-buildservice] API query to return all _real_ source packages
  • From: Adrian Schröter <adrian@xxxxxxx>
  • Date: Mon, 13 May 2019 08:31:07 +0200
  • Message-id: <1954180.6sIuiViiQk@linux-ywca>
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


and <bcntsynctag> when it is a multi-spec

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/

<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'/>

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

if exists(multibuild_name + '.spec'):
run that spec the same way multi-spec did
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

However, back to the original problem.


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$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@xxxxxxx

To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >