On 3/31/24 11:49, Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>> I am saying maybe those patches should be eliminated in favor of our
>> tree including build options that would produce the same result.
>
> I don't really see how that can be expected to work sanely.
> It turns the responsibility for platform-specific build issues
> on its head, and it doesn't work at all for issues discovered
> after we make a release. The normal understanding of how you
> can vet a distro's package is that you look at the package
> contents (the SRPM in Red Hat world and whatever the equivalent
> concept is elsewhere), check that the contained tarball
> matches upstream and that the patches and build instructions
> look sane, and then build it locally and check for a match to
> the distro's binary package. Even if we could overcome the
> obstacles to putting the patch files into the upstream tarball,
> we're surely not going to include the build instructions, so
> we'd not have moved the needle very far in terms of whether the
> packager could do something malicious.
True enough I guess.
But it has always bothered me how many patches get applied to the
upstream tarballs by the OS package builders. Some of them, e.g. glibc
on RHEL 7, include more than 1000 patches that you would have to
manually vet if you cared enough and had the skills. Last time I looked
at the openssl package sources it was similar in volume and complexity.
They might as well be called forks if everyone were being honest about it...
I know our PGDG packages are no big deal compared to that, fortunately.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com