Why not do what python and ffmpeg do for multiple versions.

We have multiple python versions and ffmpeg3 ffmpeg4 and ffmpeg5. Why not ImageMagic and ImageMagicv3?

Create a obs and obsv3 repos (non-obs and non-obsv3 too?) put the obsv3 repository in for those that want it.

Users would do this to get the v3 version:

zypper rm ImageMagic

zypper in ImageMagicv3

The executable names stay the same but the rpm gets fetched from the obsv3 repo.

Larry (retired AT&T/NCR and HP Unix Engineer assigned to Walmart Support)

Jan Engelhardt <jengelh@inai.de> writes:

On Thursday 2022-08-11 09:15, Dan Čermák wrote:

But I think it could be addressed by adding support for different x86_64
baselines in rpm, zypper & dnf, podman, docker, etc., so that we can get
away with rebuilding just a small subset of packages, where a newer
baseline actually *matters*. That will not result in a terrible strain
on our workers, while also allowing users of old hardware to still use
openSUSE.

How hard could it be? glibc has been built as glibc and glibc.i686
for a long time (and now it's _multibuilded, but still doing the
same).

The problem is that i686 and x86_64 are distinct architectures for
rpm. x86_64v2 and x86_64v3 are not, these are "arbitrary" subsets of the
full x86_64 instruction set that have just been defined as certain
baselines. RPM has no notion of these, it will see both builds as x86_64
and tools like zypper or dnf will then probably the one with the higher
NEVR. The only solution at the moment is to build into different
repositories, but then you have to either rebuild *everything* or copy
over a ton of packages from x86_64v1 into the x86_64v2/v3 repository.

And then there's containers as well, which do not understand baselines
either...


Cheers,

Dan