On 01.09.2021 17:55, Jan Engelhardt wrote:
On Wednesday 2021-09-01 15:58, Andrei Borzenkov wrote:
This means *building* binary packages inside of openSUSE:Leap:15.3 which entirely defeats the new workflow of importing existing binary packages built inside of SLE (Backport).
I tried to open issue for OBS search, but response was "not a bug":
"But all of this is not an OBS code issue. Either report it for software.o.o or to the leap 15.3 release managers."
Personally I still think this *is* OBS issue - it lacks API necessary to search for imported binary packages.
Hold the thought. OBS has a few commands to ask for that.
The SLE15 packages are not imported/aggregated, but _inherited_, and furthermore, only inherited _for building_.
Sorry, I am not OBS developer so I am not aware of exact technical distinction between "imported", "aggregated" or "inherited". I used "imported" as meaning "packages are built in some other project and result is made available via this project". I see now that "inherited" is probably the correct one here.
Leap15.3 has the same relationship to SLE15 like devel:languages:python to openSUSE:Factory.
No, it does not. Leap 15.3 has <project name="openSUSE:Leap:15.3"> <title/> <description>openSUSE Leap borrows packages from SLE. The content of the build media is almost the same as Leap:15.2, but the development is drastic different. It includes the binaries (instead of the sources) directly from SLE. https://lists.opensuse.org/opensuse-factory/2020-04/msg00165.html </description> <link project="openSUSE:Backports:SLE-15-SP3"/> <link project="SUSE:SLE-15-SP3:GA"/> and those two "link" entries are what causes all this problem. From the available documentation (https://en.opensuse.org/openSUSE:Build_Service_Concept_project_linking): ---><--- All source packages which are available in openSUSE:Factory are now also available openSUSE:Factory:Staging project. They can be checked out or branched. Please note that *they do not get listed by default, when you list the project content*. When a linked project is published, all binaries from rebuilt packages are published but any binaries from the source project which are not rebuilt are not published. Any installation should have repos from both the <link> project and the source project. ---><---
You would never find coreutils under python.
All of this reasoning was fine as long as linking was used only as internal tool (like example above Factory => Factory:Staging) and was invisible to end users. But now this is used to *publish distribution* and this has direct end user visibility. Besides as mentioned this is the wrong example.
Now then, OBS can be queried for build-time package inheritance:
osc buildinfo openSUSE:Leap:15.3/pandoc standard x86_64
This contains coreutils, and the location it is sourced from.
And how does it help to answer the question "is pandoc available for openSUSE Leap 15.3"?
search.opensuse.org could make use of this.
How? The query on s.o.o is "find all distributions/repositories where this package is available". You start with known distribution (project), but that is exactly what user tries to find.
Secondly, one could make Leap use aggregation instead. Though using more disk space, then at least, ("list binary packages available via this project")
osc ls -b openSUSE:Leap:15.3
would show coreutils, which search.opensuse.org could capitalize on as well (but I think it does not currently process binaries at all, just obs-level source packages).
Still not helpful for the end-user, but at least I hope I could provide a hypothesis on why people think it's not an OBS "problem". search.opensuse.org really needs to special-case openSUSE:Leap:* ... unfortunately - but in the same way as Leap:* needs special-casing in zypper.
s.o.o is not the only tool as I already answered elsewhere. When identical quirks to work around server behavior must be maintained in more than one place something is not right with server behavior. Of course is it not OBS "problem" as such - OBS behaves as intended, it did not expect "misuse" of project linking for distribution publishing.