Stop populating os and arch in the lead structure

[pmatilai]

The lead structure is obsolete for over 20 years, and except for the rpm file magic, nothing must be relying on that (incomplete and insufficient) data being there. The v6 format will be a nice opportunity to stop populating that data at all, which means we get to drop all the arch number madness from arch code and rpmrc too.

[dralley]

This is true even of the "major" file format version number? Of all the fields, that one seems like it could eventually have some potential use?

[dralley]

@pmatilai Just noting this - this is an instance where existing versions of rpm don't have forwards compatibility, they will yield a hard failure when reading RPMs built in this way

https://github.com/rpm-software-management/rpm/blob/4afe2d14d33db82ccb41c0a8d5eb1a4db90762fc/lib/rpmlead.c#L98-L105

[stderr] + rpm -vv --checksig /out/test.rpm
...
[stdout] error: /out/test.rpm: illegal signature type

https://github.com/rpm-rs/rpm/actions/runs/4371356425/jobs/7647160417#step:5:876

[dralley]

I've filed https://github.com/rpm-software-management/rpm/issues/2423

[pmatilai]

Thinking some more, not populating the lead will only hurt compatibility with zero actual benefits. What is beneficial though is not populating the os/arch information because that is not used by any rpm in this millenium in any form, but forces us to carry these artificial arch/os numbers around and even has some associated bugs (like values changing on resign)

[pmatilai]

Dropping from 4.20, as there's zero benefit to doing so just now. We're not bumping the soname in 4.20 so we couldn't remove rpmGetArchInfo() / rpmGetOsInfo() from the API and so we couldn't remove the associated number data yet either. And the bug where the lead changed on sign/unsign was fixed too in the meanwhile, so it wouldn't help even that. We've waited this long, we can wait a little more.

[pmatilai]

Done in #3017