build: allow for being consumed in a (discouraged) form of snapshots

[jnpkrn]

This is meant as a lean, customized policy driven alternative
to the original proposal by Jan Friesse jfriesse@redhat.com that
balances the inherent trade-off in the opposite direction, so that the
configure.ac script is practically untouched and more weight and policy
is hardcoded in git-version-gen. Problem with that approach stems from
(avoidable) effective fork of the respective gnulib's module and imposed
maintenance burden.

Speaking for libqb in particular, we should nonetheless make it
absolutely clear such in-development snapshots are nothing more,
nothing binding (not to think of viral injection of these bits
into circle of dependent packages upon their rebuilds), since the
changes accumulated since the last official release should only be
assumed firmly committed at the point the new release is cut (may
happen 99% of time with snapshots but no accountability from our
side for the complementary inter-release twists...), which is exactly
when many possibly unanticipated variables like correct SONAME
versions get to reflect what's appropriate.
Also, OpenPGP signature constitutes something more eligible for
one's trust than (provably) bit/content unstable archives without
the possibility of an independent authenticity/integrity verification.

Therefore, the only thinkable and upstream-approved use cases
for such snapshots are development-only purposes (CI et al.)!

Signed-off-by: Jan Pokorný jpokorny@redhat.com

[chrissie-c]

The travis CI build failure looks odd for this. is it related or is it just Travis being weird (again)?

[jnpkrn]

Looks like unanticipated, activistic "seriously? you might cause something!",
rather unwanted "thoughtfulness". Let me try something with umask or chmod.

[jnpkrn]

Of course, it was a matter of make distcheck that copies sources
into a separate directory marking them read-only (so as to catch the
case that the build recipes attempt to modify source files in their
source location as opposed producing the modified copy into the
build one, which is an error), and consequently, such untouched
sources to be distributed are copied to distribution directory
(non-writability being retained), but there, it's legal to modify
files from dist-hook, but as documented, one should rather mark
them writable again first (and mv is actually reasonably safe
in a way it asks for confirmation when read-only file is to be
replaced, which is exactly what made the CI timeout elapse).

Now the file gets marked as writable prior to being replaced
(as opposed to mv -f since we'd like to know about any other
possible issues).

Also, noticed that autoreconf needs to be invoked with -f when
the VERSION in generated configure script needs to be reflected
truthfully (another precondition is that no .*version files are
present, i.e., at least make maintainer-clean, if not distclean,
shall be called in advance, but that shall be clear already).
Hence extended autogen.sh to that effect.

[jfriesse]

Just a few (biased) comments:

• If you try diff gnulib and libqb version of git-version-gen you will find that they already differs. So technically speaking, you are already maintain a fork
• Use git archive stored version tag #320 is based on assumption, that non version tagged archives should not be built at all. This PR is based on idea to "care to bump "X.Y.Z-yank" template below upon each release very desirable". Isn't that going against main idea of git-version-gen?
• Eventho I must say I quite like this alternative aproach, it is showing it's weakness because configure.ac has to be modified to pristine version during dist-hook.
• As long as I didn't overlooked something, make rpm will not work and alternative to 0b07907 should be ported.

[chrissie-c]

I'm generally in favour of this approach. The language in the messages needs updating to be a little less ... archaic though.

[jnpkrn]

On 11/09/18 00:03 -0700, Jan Friesse wrote: Just a few (biased) comments: - If you try diff gnulib and libqb version of `git-version-gen` you will find that they already differs. So technically speaking, you are already maintain a fork

Yes, and both me and previously David were too lazy to attempt upstreaming that change. I think it would have higher chances than with your modification, but YMMV. OTOH, it was really a maintainer's error to use a light-weight tag in the situations all other tags are signed/annotated. For libqb, only these offenders will stand out:

v0.17.0.rc1 v0.17.1-rc1 v1.0rc3

So my take is that reverting to upstream-only version while making a mental note to always get the tagging right is also a viable contigency strategy for libqb going forward.

- #320 is based on assumption, that non version tagged archives should not be built at all. This PR is based on idea to "care to bump "X.Y.Z-yank" template below upon each release very desirable". Isn't that going against main idea of git-version-gen?

Depends on the intended use cases, really, since having this provision, the thinkable CI pipeline doesn't even need the installed git (which slowly becomes bloated, with basic files totalling at around 45 MB) -- just "curl $ARCHIVE_URL | tar xzf-" and you are good to roll. Libqb is currently not in the state where additional VCS history would be a major bandwidth overhead, still less data to be transferred nonetheless, which may be optimized further (export-ignore in .gitattributes, e.g. Travis CI and COPR/tito related files are eligible).

- Eventho I must say I quite like this alternative aproach, it is showing it's weakness because configure.ac has to be modified to pristine version during dist-hook.

Nope, in standard releases, that change is a no-op (distribution made from this distribution will be 1:1 wrt. this file), and it's in place only to save "make distcheck" run on arbitrarily fetched (incl. on-the-fly archive) tree. I would not call this a weakness; I think it would be possible to move that transformation to distcheck-hook and make it apparent in autogen.sh that in particular cases, self-reincarnating tarballs (as in "make dist" or "make rpm") shall be refrained (unless it's deemed subsumed with "use genuine releases" already).

- As long as I didn't overlooked something, make rpm will not work and alternative to 0b07907 should be ported.

See above, snapshots are not meant as a source for further redistribution, with one big exception, a test RPM build, perhaps. So I fixed this to work here as well in the force-pushed commit.

…

-- Jan (Poki)

[jnpkrn]

On 11/09/18 00:31 -0700, Chrissie Caulfield wrote: I'm generally in favour of this approach. The language in the messages needs updating to be a little less ... archaic though.

The purpose to fit those messages into 80 characters was fulfilled and this is turning into bikeshedding around exact wording for a marginal part nobody but the developers should ever see, I am afraid (note that the genuine tarballs come with configure script readily pregenerated).

…

-- Jan (Poki)

[jfriesse]

@jnpkrn I don't understand why are you still talking something about CI. The reason for implementing that feature was (at least for corosync) to mitigate problems with github release page, where people tends to use "Source code" link (probably not that much problem for libqb, but quite a big for projects which doesn't use release page at all (corosync/kronosnet)). If it also helps CI, good, but it's (at least for me) just nice side effect.

[jnpkrn]

On 11/09/18 02:52 -0700, Jan Friesse wrote: @jnpkrn I don't understand why are you still talking something about CI. The reason for implementing that feature was (at least for corosync) to mitigate problems with github release page, where people tends to use "Source code" link (probably not that much problem for libqb, but quite a big for projects which doesn't use release page at all (corosync/kronosnet)). If it also helps CI, good, but it's (at least for me) just nice side effect.

Frankly, I don't care about corosync/kronosnet context here. The choice has already been done there and it may work for these projects and their workflows well, while the same would be suboptimal for libqb. In libqb context, we have proper releases and that logic by GitHub damages that intention without a possibility of turning this redundant "well-intentionessness" off (is this accidental or on purpose? for instance, GitLab seems to be a lot less agressive about leading bycomers to download the per-tag snapshots: https://gitlab.gnome.org/GNOME/vte/tags). I think hosting these proper releases at clusterlab.org was discussed at some point in the past, perhaps it would be the most sane thing to do, along with instructing people in README where to look for new releases. Consequently, if the consumability backed with "git archive" is desired for libqb regardless, the only thinkable use-case is CI and development in general. When unfortunately confused people get to download such a form also for tagged release, they'd get warned by `./autogen.sh` they likely don't want to use that as opposed to proper releases (but at least, if they are insistent, they'll avoid `UNKNOWN` version indication now as well, see #312). I think that's preferred and the most sane outcome we can get. A side note since I've been looking at associated issues: one cannot use `git archive` locally with GH location directly, it seems: isaacs/github#554 Perhaps one more incentive to move away from GH as an authoritative code hosting, along with the mentioned overly aggressive emphasis on "get tarball from us [and don't even think about looking elsewhere]" (https://lists.clusterlabs.org/pipermail/developers/2018-June/001241.html)

…

-- Jan (Poki)