Tarball builds in the new world order

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Tarball builds in the new world order
Дата
Msg-id 3552543.1713909947@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Tarball builds in the new world order  (Greg Sabino Mullane <htamfids@gmail.com>)
Re: Tarball builds in the new world order  (Peter Eisentraut <peter@eisentraut.org>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: GUC-ify walsender MAX_SEND_SIZE constant
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?