Instead of hand-rolling our own systemd integration, we can rely on RPM
macros maintained for us. This results in the following changes in the
main package's scriptlets:

    --- scripts.old	2019-02-14 10:50:21.039974337 +0100
    +++ scripts.new	2019-02-14 10:49:24.649144061 +0100
    @@ -12,14 +12,24 @@

     exit 0
     postinstall scriptlet (using /bin/sh):
    -/bin/systemctl daemon-reload >/dev/null 2>&1 || :
    -chown varnishlog:varnish /var/log/varnish/
     /sbin/ldconfig
    +
    +if [ $1 -eq 1 ] ; then
    +        # Initial installation
    +        systemctl preset varnish varnishncsa >/dev/null 2>&1 || :
    +fi
     preuninstall scriptlet (using /bin/sh):
    -if [ $1 -lt 1 ]; then
    -  # Package removal, not upgrade
    -  /bin/systemctl --no-reload disable varnish.service > /dev/null 2>&1 || :
    -  /bin/systemctl stop varnish.service > /dev/null 2>&1 || :
    -  /bin/systemctl stop varnishncsa.service > /dev/null 2>&1 || :
    +
    +if [ $1 -eq 0 ] ; then
    +        # Package removal, not upgrade
    +        systemctl --no-reload disable varnish varnishncsa > /dev/null 2>&1 || :
    +        systemctl stop varnish varnishncsa > /dev/null 2>&1 || :
     fi
    -postuninstall program: /sbin/ldconfig
    +postuninstall scriptlet (using /bin/sh):
    +/sbin/ldconfig
    +
    +systemctl daemon-reload >/dev/null 2>&1 || :
    +if [ $1 -ge 1 ] ; then
    +        # Package upgrade, not uninstall
    +        systemctl try-restart varnish varnishncsa >/dev/null 2>&1 || :
    +fi

The only major change is that the varnish and varnishncsa services will
be restarted during a varnish upgrade. This is needed because otherwise
reloading a VCL that uses vmod_std after the upgrade (and without
restarting) would fail because the running varnishd wouldn't recognize
the shared object's expected ABI.

One unrelated change is the handling of /var/log/varnish/ ownership. As
it was done until now a fresh install would yield a corrupted package:

    $ rpm --verify varnish
    .....UG..    /var/log/varnish

Since we already create the users and group before installing the files,
we can already ask RPM to chown the directory itself.

We build againt a bootstrapped "dist" archive so we can save a few
cycles here and there by not installing a redundant build system that
is not in use inside the schroot.

When we are building the binary packages inside an schroot, they will be
fetched and installed. We don't need them on the host running sbuild.

Fixes #101

unknown-section varnish-6.0/web
  Section: @SECTION@/web -> Section: web
  Section: @SECTION/libdevel -> libdevel
  The substitution line in the package-deb script got removed:
  sed -i -e "s|@SECTION@|varnish-$MAJOR|" "$DIST_DIR/debian/control

copyright-without-copyright-notice:
  The copyright file expected a certain 3 line header:
      Copyright YYYY Firstname Lastname <address@example.com>
      Copr. YYYY-YYYY Firstname Lastname <address@example.com>
      © YYYY,YYYY Firstname Lastname <address@example.com>

Added debian/source/format file with content "1.0"

READMEs:
 - Installing again the once-installed README.rst and README.packaging

VCLs:
- A non-commented version of builtin.vcl is not installed into
/usr/share/doc/varnish/examples anymore.

Fixes #104

While ultimately the goal is to automate virtual provides and requires
to the extent of out-of-tree modules, considering that for now package
maintainers would have to manually adjust their requirements, they
couldn't easily manage either 32bit or 64bit dependencies in a single
Requires tag. While we don't ship 32bit packages, distributions like
Fedora do.

Now a user can easily target the right architecture on a multilib system
with a single dependency:

    Requires: varnishd(abi)%{?_isa} = sha1

This is already part of the upgrade notes I'm redacting and I will amend
the wiki accordingly.

In other words on 64bit systems:

    Provides: varnishd(abi)(64bit) = sha1
    Provides: varnishd(vrt)(64bit) = x.y

Same as VMOD virtual provides.

Although this one wasn't handled before so I'm not certain it makes any
difference to just say sections "web" and "libdev" even for our repos.

And simplify its neighbor.

We can already deduce the name expected by DPKG or RPM from what we
have.

With more comments this time!

As per discussion, to better facilitate alternate init-
systems and re-packaging efforts, we want to keep in the
sysv versions of the packaging files.

In other words, we get that part of the release tag from upstream
already.

Same as traditional shared objects, it now looks like this:

    varnish = x.y.z-r
    varnish(x86-64) = x.y.z-r
    libvarnishapi.so.1()(64bit)
    libvarnishapi.so.1(LIBVARNISHAPI_2.0)(64bit)
    varnishd(abi) = sha1
    varnishd(vrt) = a.b
    vmod(blob)(64bit) = x.y.z-r
    vmod(directors)(64bit) = x.y.z-r
    vmod(purge)(64bit) = x.y.z-r
    vmod(std)(64bit) = x.y.z-r
    vmod(vtc)(64bit) = x.y.z-r

Maybe varnishd(*) provides should be ISA-bits-aware too.

Since we wrap calls to the original find-provides it loses the ability
to do that so it becomes our responsibility.

A bit fragile when it comes to grabbing the version.