Re: Tarball builds in the new world order

Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> On 24.04.24 00:05, Tom Lane wrote:
>> # Export the selected git ref
>> git archive ${gitref} | tar xf - -C pgsql

> Where does ${gitref} come from? Why doesn't this line use git archive
> HEAD | ... ?

${gitref} is an argument to the script, specifying the commit
to be packaged. HEAD would certainly not work when trying to
package a back-branch release, and in general it would hardly
ever be what you want if your goal is to make a reproducible
package.

>> What I suggest is doing this in mk-one-release:
>> -make dist
>> +make dist PG_COMMIT_HASH=${gitref}

> I suppose we could do something like that, but we'd also need to come up
> with a meson version.

Packaging via meson is years away yet IMO, so I'm unconcerned
about that for now. See below.

> (Let's not use "hash" though, since other ways to commit specify a
> commit can be used.)

OK, do you have a different term in mind?

>> This change seems like a good thing anyway for anyone who's tempted
>> to use "make dist" manually, since they wouldn't necessarily want
>> to package HEAD either.

> A tin-foil-hat argument is that we might not want to encourage that,
> because for reproducibility, we need a known git commit and also a known
> implementation of make dist. If in the future someone uses the make
> dist implementation of PG19 to build a tarball for PG17, it might not
> come out the same way as using the make dist implementation of PG17.

Of course. The entire reason why this script invokes "make dist",
rather than implementing the behavior for itself, is so that
branch-specific behaviors can be accounted for in the branches
not here. (To be clear, the script has no idea which branch
it's packaging --- that's implicit in the commit ID.)

Because of that, I really don't want to rely on some equivalent
meson infrastructure until it's available in all the live branches.
v15 will be EOL in 3.5 years, and that's more or less the time frame
that we've spoken of for dropping the makefile infrastructure, so
I don't think that's an unreasonable plan.

regards, tom lane