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
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 |