On 3/31/24 11:49, Tom Lane wrote:
Joe Conway <m...@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
