Re: Release scripts ready for 3.27.3 - Quick HOWTO

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

On Thu, 2017-11-30 at 11:44 -0600, Michael Catanzaro wrote:
> On 11/30/2017 11:15 AM, Tristan Van Berkom wrote:
> > $ cd ../gnome-modulesets
> > $ bst track core-deps/m4-common.bst base/crates.bst
> >
> > The result of this is we'll have specific commit references for the
> > above two components which dont have any corresponding tarballs, which
> > is fine.
>
> Actually I don't think that's fine. m4-common is used for generating 
> release tarballs, not building them; it should not be required for the 
> release. And I'm not sure what crates is, but if that's Rust crates, 
> they should all be included in the librsvg tarball.

I disagree here.

I think that we want to avoid as much as possible, the maintenance of
multiple build topologies.

Yes, m4-common provides what modules need to create a distchecked
tarball, but in our builds; do we really want to touch that configure
script, even though it's there ? I think not.

Also, builds where you invoke autogen.sh even though there is a
configure script *might work* with jhbuild release modulesets, but that
is only by accident; because you happen to have m4-common lying around,
nothing happens to be lying around with BuildStream.

As for crates; you are right that librsvg tarballs wont require it, but
again removing it is just a question about introducing more special
cases left and right which you really dont need - it might as well be
there but ignored, rather than investing human effort maintaining two
separate builds.

> So we have some modules that are needed when building from git, but not 
> from tarballs. Probably modules that don't have corresponding tarballs 
> should be dropped from the bst moduleset. I think that's what the 
> original convert-to-tarballs script did.

convert-to-tarballs.py originally has a very special case for
explicitly removing m4-tarball actually, however it does leave these
dangling dependencies on the non-existent m4-tarball module.

Cheers,
    -Tristan