On Mon, Dec 2, 2019 at 10:44 AM Jan Engelhardt
On Monday 2019-12-02 13:52, Neal Gompa wrote:
So you don't support name.arch package requests in OBS?
Two reasons:
1. There is one bs_sched instance for each %_isa (design decision done many moons ago, possibly to have at least some little multiprocessing). In this "enclave" so to speak, there are generally only packages for said %_isa.
mkbaselibs is used inside the i586 space to repackage (part of) i586 rpms with i586 code into a x86_64 rpm, which are then copied to the x86_64 space with an explicit ExportFilter.
That is a horrible way to handle this, because it means that: 1. These packages must be manually defined 2. These packages are lies (they pretend to be x86_64 when they are really x86_32 packages)
Attention is paid towards there being no conflicting files whatsoever, which is otherwise not the case when you install both libfoo1.i586 and libfoo1.x86_64 (e.g. a LICENSE file).
In that particular example, rpm handles it just fine, since the file is identical across arches. Fedora multiarch packages generally do have these things handled.
2. I suppose many parts of bs_sched and obs-build evaluate just %{NAME} (without %{ARCH}), and there simply is no rpm file that has NAME="libfoo1.i586".
Nor using the name%{?_isa} requests to pull multiarch deps? Why not?
There are never any "non-home" ISAs available as install candidates, so our specfiles never needed to bother with that case. Certainly saves clutter in that particular place (might generate it elsewhere, tho).
That is not true. Even openSUSE package repos are multiarched. There's one set of repodata for x86_64 and "i586" packages. I can see and install them as multiarch candidates just fine. And runtime dependencies for Wine on Fedora and openSUSE rely on this property. -- 真実はいつも一つ!/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org