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".
"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
<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.
and those two "link" entries are what causes all this problem. From the
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
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
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"?
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".
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.