Things we ought to do to improve our packaging

Augie Fackler raf at
Tue Aug 6 14:01:03 CDT 2013

On Tue, Aug 06, 2013 at 01:53:34PM -0500, Matt Mackall wrote:
> [this discussion needs to be cross-posted]
> We've got a few long-standing problems with our current packaging:
> - lag official release
> - not automated
> - not reproduceable by third parties
> - not signed
> - lack nightly builds
> - notable missing platforms (RHEL)
> - not uniform in configuration
> Our attitude to date has been "well, we're not really in charge of that,
> that's done unofficially by volunteers". I think we've reached a point
> where this needs to start changing.
> In an ideal world, a release would work like this:
> - I tag the release
> - I push it
> - Automated builders kick off on a bunch of VMs or hosts
> - Builders run stock makefile targets or scripts in tarball
> - Packages get signed
> - Packages get uploaded to one or more locations, including
> - Download links get updated
> Importantly, this same process would also be used to produce automated
> nightly builds for testing and bug reporting and discovering packaging
> problems before release dates.
> The job of packagers would thus shift from "(manually?) building and
> uploading binaries" to "making sure the committed build rules are
> correct and up-to-date".
> I think this also needs to be inclusive of builds for packaging systems
> (Debian, Ubuntu, RHEL, Centos, Solaris, Pypi, etc.). These actually
> suffer from more or less the same problems even though the distribution
> model is different. So we should be building nightlies and release
> builds for these systems and be more directly responsible for quality
> and timeliness here as well.

This honestly sounds like a great improvement, given how stale the
packages for Ubuntu tend to be, and how some packagers took it upon
themselves in the past to enable all the extensions.

> --
> Mathematics is the supreme nostalgia of our time.
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at

More information about the Mercurial-devel mailing list