On Fri, Jan 10, 2020 at 5:05 AM Florian Weimer <fweimer(a)redhat.com> wrote:
* Neal Gompa:
> On Fri, Jan 10, 2020 at 4:28 AM Florian Weimer <fweimer(a)redhat.com> wrote:
>>
>> We do not want to change the RPM architecture, so that users still can
>> install third-party software. This means that we need to change the
>> dist tag to avoid confusion.
>>
>
> Changing the RPM architecture does not necessarily mean that you
> wouldn't remain compatible with baseline x86_64. For example,
> OpenMandriva's build of the distribution optimized for first
> generation AMD Ryzen systems uses the "znver1" RPM architecture, but
> the "znver1" architecture is deliberately considered compatible with
> x86_64, so packages that are "x86_64" are still installable. There are
> numerous examples of this for 32-bit x86, and there's no reason we
> couldn't do this for 64-bit x86.
But the value of %_arch still changes, right?
I believe this will break things, like this:
| F ?= $(shell test ! -e /etc/fedora-release && echo 0; test -e
/etc/fedora-release && rpm --eval %{fedora})
| ARCH ?= $(shell test ! -e /etc/fedora-release && uname -m; test -e
/etc/fedora-release && rpm --eval %{_arch})
| MOCK_CFG ?= $(shell test -e /etc/fedora-release && echo
fedora-$(F)-$(ARCH))
It will break _that_ specifically, yes. But it is not okay to make
this muddier than it already is. If we are changing the definition of
x86_64 in Fedora, that's one thing. But you are not proposing that.
Therefore, it needs a different architecture classification.
And as an aside, that particular code would still break even if you
were using just a weird DistTag change, because a separate build root
means a separate mock configuration.
--
真実はいつも一つ!/ Always, there's only one truth!