Mailinglist Archive: opensuse-buildservice (74 mails)

< Previous Next >
Re: [opensuse-buildservice] API query to return all _real_ source packages
  • From: Jimmy Berry <jberry@xxxxxxxx>
  • Date: Fri, 10 May 2019 15:22:51 -0500
  • Message-id: <2237605.4Nne1lWOcd@boomba.local>
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
package. 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.

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.


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

< Previous Next >
Follow Ups