couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From till <>
Subject Re: tracking upstream dependencies
Date Fri, 26 Nov 2010 21:02:40 GMT
E.g. for packaging on distros like FreeBSD you usually download the
the software in an unmodified state from an official mirror [of the
software] and then patch it before building and registering the

So e.g., I'd download CouchDB from an apache mirror and then patch
whatever I need and then it runs ./configure, make, etc.. All
configure by the port's Makefile.

This of course relies on people not re-releasing a different version
with the same ID, etc.. But of course validation of checksums of the
archives are build in to avoid this sort of thing from happening.

How often does it happen that CouchDB has to patch/modify software
like Mochiweb? And what are the chances to push the patches to
upstream prior to releasing CouchDB. I realize this could slow down
the release process, but it would make a cleaner build.


On Fri, Nov 26, 2010 at 9:44 PM, Noah Slater <> wrote:
> The release artefact absolutely should not, ever, pull down files from the network. However,
I can see a way forward by having the bootstrap script manage the bundling of external dependancies.
The bootstrap script should only ever be run from a checkout of the code. Whatever it downloaded
and prepared would be included as part of the release artefact.
> But assuming we got this working, we face the problem of not being able to apply our
own patches. Also, the software it downloads might have some bug in it that was introduced
a week, day, or hour before the release was made. How would we defend ourselves against this?
> On 26 Nov 2010, at 20:38, Adam Kocoloski wrote:
>> Hi all, there's a discussion in the 1.0.2 voting thread about better tracking of
upstream dependencies like mochiweb.  One point that keeps getting brought up is that build
systems should not need network access.  Is that a rule which applies to building from an
SCM repo, or only to builds of release artifacts?
>> I think we might be able to make our lives easier if we only bundled upstream dependencies
at release generation time, and otherwise relied on the build system to retrieve them.  For
a concrete example, BigCouch recently switched to using rebar for dependency resolution.  The
main repo at only has the couch OTP application in it,
the other dependencies are pulled from forked git repositories containing CouchDB-specific
branches and tags such as
>> If the no-network-access rule does apply to SCM builds, we might consider bundling
full git repos instead of doing the source code copy/paste dance.  At least this would allow
a clearer indication of where we stand w.r.t upstream.  Best,
>> Adam

View raw message