Tarball builds in the new world order - Mailing list pgsql-hackers

From Tom Lane
Subject Tarball builds in the new world order
Date
Msg-id 3552543.1713909947@sss.pgh.pa.us
Whole thread Raw
Responses Re: Tarball builds in the new world order
Re: Tarball builds in the new world order
List pgsql-hackers
With one eye on the beta-release calendar, I thought it'd be a
good idea to test whether our tarball build script works for
the new plan where we'll use "git archive" instead of the
traditional process.

It doesn't.

It makes tarballs all right, but whatever commit ID you specify
is semi-ignored, and you get a tarball corresponding to HEAD
of master.  (The PDFs come from the right version, though!)

The reason for that is that the mk-one-release script does this
(shorn of not-relevant-here details):

    export BASE=/home/pgsql
    export GIT_DIR=$BASE/postgresql.git

    mkdir pgsql

    # Export the selected git ref
    git archive ${gitref} | tar xf - -C pgsql

    cd pgsql
    ./configure

    # Produce .tar.gz and .tar.bz2 files
    make dist

Since 619bc23a1, what "make dist" does is

    $(GIT) -C $(srcdir) -c core.autocrlf=false archive --format tar.gz -9 --prefix $(distdir)/ HEAD -o
$(abs_top_builddir)/$@
    $(GIT) -C $(srcdir) -c core.autocrlf=false -c tar.tar.bz2.command='$(BZIP2) -c' archive --format tar.bz2 --prefix
$(distdir)/HEAD -o $(abs_top_builddir)/$@ 

Since GIT_DIR is set, git consults that repo not the current working
directory, so HEAD means whatever it means in a just-fetched repo,
and mk-one-release's efforts to select the ${gitref} commit mean
nothing.  (If git had tried to consult the current working directory,
it would've failed for lack of any .git subdir therein.)

I really really don't want to put version-specific coding into
mk-one-release, but fortunately I think we don't have to.
What I suggest is doing this in mk-one-release:

-make dist
+make dist PG_COMMIT_HASH=${gitref}

and changing the "make dist" rules to write $(PG_COMMIT_HASH) not
HEAD.  The extra make variable will have no effect in the back
branches, while it should cause the right thing to happen with
the new implementation of "make dist".

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.  Now, if we just do it exactly like that
then trying to "make dist" without setting PG_COMMIT_HASH will
fail, since "git archive" has no default for its <tree-ish>
argument.  I can't quite decide if that's a good thing, or if we
should hack the makefile a little further to allow PG_COMMIT_HASH
to default to HEAD.

Thoughts, better ideas?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: GUC-ify walsender MAX_SEND_SIZE constant
Next
From: Michael Paquier
Date:
Subject: Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?