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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers