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 install.
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. Till On Fri, Nov 26, 2010 at 9:44 PM, Noah Slater <nsla...@apache.org> 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 https://github.com/cloudant/bigcouch 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 >> https://github.com/cloudant/ibrowse/tree/CouchDB-1.0.1 >> >> 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 > >
