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/ @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. 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. -- Jimmy -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org