> My usual procedure is to git pull, build a distribution tarball in
> the standard way described in INSTALL.REPO, then build an
> installable package from that with the standard OpenBSD packaging
> system, which, in a nutshell
>
> 1. extracts the tarball
> 2. applies distribution patches (minor things like adjusting the
> operating system name and section titles to local conventions)
> 3. runs configure
> 4. runs make
> 5. runs make install to a fake area
> 6. uses a packing list to validate that the right files
> got installed in fake area
> 7. builds a package from the fake area
>
> This procedure implies testing both the out-of-tree build (for
> building the dist tarball) and the in-tree build (when building the
> final package). It also implies that i do testing with the real,
> final paths and interdependencies of modules that users will later
> on have on their production systems.
This looks completely reasonable.
> I can then install the resulting package into the real operating
> system, run regression suites, and do manual run-time testing.
>
> This time, the effects of git-version-gen caused failures in steps
> 1, 2, 6, and 7, and at run-time, see below for the reasons.
All your issues can be solved if you do one additional step.
git archive --format=tar.gz \
--prefix=groff-current/ HEAD \
> groff-current.tar.gz
tar xzvf groff-current.tar.gz
cd groff-current
echo 1.22.4 > .tarball-version <---
./bootstrap
./configure
make
make install
> I doubt that nowadays, anybody still uses the native build system to
> install self-compiled software directly into the operating system,
> so i don't see how that is relevant...
I do this all the time.
> right now, the string is "1.22.3.rc1.43-e7a3", with "3.rc1", even
> though this is actually a *4* release candidate.
Yes, this is a mistake. Bertrand, please fix :-)
Werner
