On Wed, May 20, 2015 at 02:10:30PM -0400, Tom Lane wrote:
> One reason why it would not be, if it's a build-time decision,
> is that it's quite unlikely that any popular packagers would build
> that way. So this would only be applicable to custom-built binaries,
> which is a pretty small class of users to begin with.
There might be appliance vendors who ship PostgreSQL along with their
product. Then, they decide they want to use the pristine tarballs for
reproducibility and accountability. If done right, they could publish
their set of configure options and a build-id or whatever, and 3rd
parties could verify the binaries they ship have not been tampered
with[1]. Granted, they could also just publish the patch for those 3rd
parties to apply as well, but that sounds slightly inelegant.
The other set of users I could think of are those who, for whatever
reason, tend to always compile PostgreSQL from source for their
company/organization. Maybe they have internal rules that requires a
custom installation prefix for all their servers or whatever. Due to
procedural requirements, or just the unwillingness to carry deltas, they
absolutely want to use the pristine tarballs as well but would be very
happy to get rid of some of the authentication methods.
That said, I agree that both examples are rather contrived and this is
more of an advocatus diaboli kind of reply.
Michael
[1] seems like PostgreSQL is in the set of packages which successfully
build reproducibly according to the Debian reproducible builds effort,
yay