On 11/7/20 2:40 PM, L A Walsh wrote:
TLDR: rpm(s) >= 4.15, can't be read, built or installed by rpm < 4.15 (specifically, 4.11).
On 2020/10/29 03:55, Simon Lees wrote:
I asked:
I don't suppose anyone thought about how users who missed a few months of internet connectivity might resync or make use of the new format rpms if they can't even install + build source-rpms.
I'm not sure how much we claim to support building openSUSE rpm's as source rpm's on there own. openSUSE rpm spec files often depend on variables that are defined in project config files in open build service, as such just using rpmbuild may result in packages not building or building with different configurations.
But is *installing* "rpms" from tumbleweed, with "rpm" on a tumbleweed install, supported?
Well we still support upgrading from Leap to Tumbleweed and upgrading older tumbleweed installs so if people update using the supported method of zypper dup someone has put in the effort to make it work I haven't looked at how they have done that.
The reason I was trying to build _rpm_ from source is to get an rpm with the "PayloadIsZstd" feature, since my local rpm doesn't have that feature. It really wouldn't help to build rpm on OBS if it would just give me an 'rpm' that I can't install on my machine due to prereqs.
The thing is, is that I was able to get down to building "rpm" but only had PayloadIsZstd as a requirement of a local attempt to build that would run with the packages and libraries I currently have installed.
I don't want to rebuild the same uninstallable binary rpm package that is currently distributed with "encrypted" (using a "secret", new new encoding(compression lib) that can _only_ be built from packages that require the same encoding in order to be installed.
I.e. I can't install the binary rpm, because it has 8 pre-reqs on other rpm packages that expand to some 30+ packages all that cannot be installed due to the fact that they require the "PayloadIsZstd" rpm feature.
I find myself unable to build the binary rpm on my system because it requires 'devel' packages all that require the 'PayloadisZstd'.
I tried building the Zstd lib, but it also requires binary packages that require the same feature -- i.e. a **circular dependency**. This disallows INSTALLING any needed rpm's that one might need to even build those same rpm's from their source rpms. I realize that sources for GNU licensed binaries appears to be included but the sources for those new binaries are inaccessible because they are encoded in the new compression scheme.
I'm pretty sure that requiring a user to only build tools in suse's OBS, as a pre-condition for satisfying GNU's requirement for including source with redistributed binaries is not considered a valid way of establishing a "locally trusted" build environment. _Part_ of the reason the sources are open is that the user may regenerate binaries on their local machines to satisfy various "chain of trust" requirements on the build tools and machine.
In a supported up to date system we provide all the tools required to view and install source rpm's, additionally to the tools you'd expect programs such as ark can open and read our rpm's just fine.
This, ultimately, boils down to variations on Ken Thompson's "Reflections on Trusting Trust" (as from: http://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustin...
From our build service you can find and inspect all the build logs along with the source tarballs, beyond that obs has the ability to verify that upstream tarballs have been used along with signature checking. The Reproducible builds team has also done a lot of work in this area so generally i'd say we are doing better then most distro's. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B