vtest2 integration revisited

[nigoroll]

Yesterday, @rfc1036 raised an issue on irc that apparently our vtest2 integration as a git submodule has broken the workflow of some packagers, who now assume that a project could be completely built from just a git clone:

I have just discovered that now the varnish repository uses the vtest2 submodule, which is a huge pain in a Debian contest. is there any chance to persuade you to use git-subtree instead?
more specifically, Debian is (slowly) moving from the old tar archives source packages to git-first workflows (multiple ones of course, it's Debian...) which can be used to directly build and generate the source packages, and submodules are hard to implement there
of course packages cannot download a submodule at build time because no network access is allowed

I have some reservations against the git-subtree approach, because I fear it would bring us back to the diverging trees as before (despite better tooling, the problem is basically the same as before - having more than one source of truth), so I would like to ponder alternative approaches - all under the premise to help packagers and specifically not make their lives harder than absolutely necessary.

Build from the dist archive

From my perspective, this is the baseline: We as a project produce a distribution archive, and it is complete and self-contained. The problem here is that apparently some packagers now have additional needs (requirements?):

some people like me like to have the full upstream history in their package repository, which I would not have if I just imported the tar archives
yes, there is a bit of a debate about packaging (and verifying the signature of) tar archives vs. git trees. but I think that the future will obviously be about preferring git trees as much as possible

Package vtest2

This option was also mentioned by Md:

if vtest2 had releases then I would just package it by itself, but since it is basically a source-only library I can only create an intermediate upstream branch in the Debian repository where I manually merge the vtest2 repository

This option was already on our list as of #3983

Split vtest into a library and a program

I maintain the position that we do not need this option to fulfill our own requirements, but if it helps packagers, why not add the option to use an external vtest for make check?

This would conflict with the plan to have certain vinyl-cache specific vtest extensions in our tree and not in the vtest tree, but that idea was already shelved by the argument that vtest should be able to use all components which run vtest.

Create a new kind of "dist archive"

If packagers now need the complete git history, why not create a gist archive (pun intended) containing all the git-bundle s of all needed projects?

Then checking out the vinyl repo would not require much more than (pseudo code)

if -f ../vtest2.bundle ; then
git submodule set-url bin/varnishtest/vtest2 ../vtest2.bundle
git -c protocol.file.allow=always submodule update --init
fi

[rfc1036]

Thanks, but the goal is to be able to build the package from a (complete) git tree. Importing a dist archive in the Debian repository always works, but I think that it is an obsolete approach since it flattens the upstream history.

Bundles are not relevant, since they are not supported by any Debian tooling: if I cannot use the upstream repository as is then the best I can do is to base the Debian branch off an intermediate upstream branch where I will manually merge the vtest2 repository.

Making vtest2 a source-only library and build-depending on it would work in theory, but would break as soon as varnish and something else will need different versions of vtest2 so I do not think that it is not a viable option for me.

[nigoroll]

summoning @wtarreau @haproxyFred : You would be affected also by this issue?

[wtarreau]

Well I don't have much of an opinion on all of this since I'm not much familiar with the problem. However I can say that as a user I'm not very fond of submodules. I tend to think that when a project employs submodules, it just means it has some dependencies (which is fine) and that submodules are easier to deal with during the development phase. But then it would make sense to just expose the two repos separately and have users pull and build them separately, without requiring submodules. A good hint is to consider that one must not be required to have git to build a project. So here if a submodule is needed, I'd make an external dependency of it (say libfoobar) and packagers would just have to maintain the two packages separately, one of which has a dependency on the other. I don't know if that helps you though.

[nigoroll]

So based on the feedback here and the last bugwash discussion, we seem to settle on

• adding releases for vtest2
• making vtest2 a build-time requirement for va^wvinyl-cache

[nigoroll]

@rfc1036 as this is going to take some time, do you see any possibility to patch up the build to make available a vtest2 bundle?
For example, could we have something like a VTEST2_GIT environment variable which configure uses to clone vtest from a local file?
See also the last bit here

[rfc1036]

The point here is how I can make vtest2 available.
If I can package vtest2 standalone (even as 0.0.$GITDATE) and build-depend on the binary package it builds then it's fine: I suppose that I can hack the varnish build system as needed to use it. But I remember that varnish needs the vtest2 source tree around, and this is the complex part for me.

[nigoroll]

bugwash: needs some digging before we can settle on a strategy

[bsdphk]

I ran into another fall-out from vtest, but it is minor:

Our gcov run assumes that all file basenames are unique, and after the vtest2 import they are not.

As long as the files are identical the gcov data is still valid.

[nigoroll]

@rfc1036 it would be great to get your feedback on vtest/VTest2#7 and #4406