[systemd-devel] no tar balls at release time

[Dave Reisner]

On Tue, Jun 23, 2015 at 01:19:54PM +0200, Kay Sievers wrote:
> On Tue, Jun 23, 2015 at 4:02 AM, Dave Reisner <d at falconindy.com> wrote:
> > On Tue, Jun 23, 2015 at 01:21:36AM +0200, Kay Sievers wrote:
> >> We currently considering to stop creating release tar balls.
> >
> > What's the motivation for this change?
> 
> We focus on git, and git only. We do not want to sign tar balls to
> distribute, but rely on signed git tags only.
> 
> Pre-building stuff to put into tar balls creates too many
> restrictions. It is just plain wrong to pre-build and ship things like
> man pages, which depend on common configure options.
> 
> > I suspect that with this, 'make
> > distcheck' will never again be run and it will eventually break
> > build configurations which don't align with what the CI tests.
> 
> We synced the "make dist" and "git archive" tar balls as much as
> possible now. Even the autotools created one will not contain any
> pre-built stuff anymore besides the autofoo itself.
> 
> We might continue to run distcheck in the CI, but we don't know
> anything for sure at that point in time, only that tar balls are not
> part of the release anymore.

To reiterate -- Arch doesn't care about tarballs going away. I'm
concerned that 'distcheck' provided some amount of pre-release sanity
checking, and I'd prefer that we don't lose that for a project which
already lacks a large amount of in-tree test coverage.

Everyone involved would benefit from something such as the following:
implement the equivalent of the kernels 'make allconfig' and use this
for the CI builds, rather than a bare "./configure" (which won't pull in
much based on the deps being installed). I realize this can't be 100% of
the options since there's conflicting and "legacy" switches (like
split-usr). However, you'll at least be giving build system more
thorough testing, and decreasing the likelihood that release day is when
broken builds are reported on the mailing list.

dR