Template RPMs should be architecture-specific (not noarch)

[Osndok]

The problem you're addressing (if any)

Qube templates that are provisioned via RPMs currently have the noarch architecture. This is clearly wrong in the technicaly sense as the contained image is very much architecture specific.

Yet, "simply changing it now" would cause a significant disruption as (AFAIK) that would cause everyone to download many gigabytes of discarded data.

Describe the solution you'd like

At the next opportunity; whenever it would be expected that one would have to "reinstall qubes to update" (4.2? 5?), we should remove the exclusive arch flag from the template rpm spec files, causing the generated rpms to be architecture-specific.

Perhaps this could even be done incrementally per template (fedora-34? 35?), until all the old noarch templates are simply retired.

Where is the value to a user, and who might that user be?

This would remove a significant roadblock to anyone wanting to port qubes to another platform (such as #4318).

This would give the qubes project an extra degree of freedom if they decide to support an additional architecture in the future.

Describe any alternative solutions you've considered

None.

Additional context

Relevant documentation you've consulted

• https://github.com/QubesOS/qubes-linux-template-builder/blob/4d8c03b9a88693fb74435d8d3dde09ea02641bb7/templates.spec#L21
• https://github.com/QubesOS/qubes-linux-template-builder/blob/4d8c03b9a88693fb74435d8d3dde09ea02641bb7/build_template_rpm#L46

Related, non-duplicate issues

• 4318

[andrewdavidwong]

Is this already covered by https://github.com/QubesOS/qubes-issues/issues/2534?

[Osndok]

On a cursory reading, that ticket seems like a somewhat-vague grand plan... whereas this is ticket is just asking for one field to be changed to be more correct. It's very specific, compatible with the existing infrastructure/tooling, and ought to be far easier and actionable.

[marmarek]

Yes, sounds like a good idea to keep this separate from #2534 (even if just a subtask). As for the change itself, sounds good, and I think should not even have too much untended side effects, as the update process explicitly excludes already installed templates. The reason for having noarch in the first place, is to avoid rpmbuild applying all its arch-specific post-processing (extracting debuginfo etc), that is both undesired here and sometimes simply incompatible with the template content. That said, there are likely better ways to avoid it (maybe even rpmbuild is now smart enough to do the right thing by default).