On Fri, Dec 17, 2021 at 4:59 PM Colin Walters <walters(a)verbum.org> wrote:
On Mon, Dec 13, 2021, at 5:21 PM, Tom Stellard wrote:
>
> Did you test the impact this has on package build times? Particularly
> packages like llvm, clang, webkit2gtk3, etc. that have very large
> debuginfo files?
I think far too often the culture here is "make $change for all RPMs". But
this "everything is an RPM" mindset can lead to outcomes and methodology that is
at best weird.
For e.g. "let's try building with newer gcc", it would seem far better to
me to e.g. start with the things that are in Fedora CoreOS or Workstation or whatever.
(And, optionally their build dependencies)
Subset validation is very useful, yes, but fundamentally the Rawhide
corpus is used to shake out GCC in the first place. It's a big part of
how GCC new stable releases become so good. If we don't do it,
basically nobody will.
For *this* particular change, the value of pre-signing the -debug
RPMs seems...weak. Or even the `-devel` RPMs. Now, obviously choosing *which* binaries
to sign would require some thought.
But I think that's worth doing instead of blindly doing everything.
I'm not sure I agree. Outputs become inputs for other processes, and I
think people generally prefer that the integrity of those inputs could
be assured. If we'd want the integrity of the filesystem to be assured
for runtime components, I see no reason that we wouldn't want it for
development components and build-time components too. Moreover, as
infrastructure for granular, network-based access for those things
becomes a reality, having signed blobs for those things becomes more
valuable so that privileged processes can be reasonably assured that
they aren't tampered with.
--
真実はいつも一つ!/ Always, there's only one truth!