Re: Tarball builds in the new world order

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Magnus Hagander <magnus(at)hagander(dot)net>
Subject: Re: Tarball builds in the new world order
Date: 2024-04-28 19:44:10
Message-ID: 790492.1714333450@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> Why is it that the .gitrevision file is only created here, instead of
> being added to the tarball that "git archive" produces? Adding an
> argument like
> --add-virtual-file $(distdir)/.gitrevision:$(GIT_REFSPEC)
> to the git archive call should suffice.

I think we don't want to do that. In the first place, it's redundant
because "git archive" includes the commit hash in the tar header,
and in the second place it gets away from the concept that the tarball
contains exactly what is in our git tree.

Now admittedly, if anyone's built tooling that relies on the presence
of the .gitrevision file, they might prefer that we keep on including
it. But I'm not sure anyone has, and in any case I think switching
to the git-approved way of incorporating the hash is the best thing
in the long run.

What I'm thinking of doing, as soon as we've sorted the tarball
creation process, is to make a test tarball available to the
packagers group so that anyone interested can start working on
updating their packaging process for the new approach. Hopefully,
if anyone's especially unhappy about omitting .gitrevision, they'll
speak up.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2024-04-29 01:12:48 A failure in prepared_xacts test
Previous Message Heikki Linnakangas 2024-04-28 19:36:33 Re: Refactoring backend fork+exec code