Re: Stable source repository

[Rich Pixley <rich.pixley@palm.com>]

Locally, we have a comparable problem.  Not only can we not rely on 
external repositories for archiving code, but given the volume of 
downloads we'd be placing, we can't really even rely on external 
repositories for current versions due to bandwidth constraints, (most 
facilities would resent the load our company would place on their servers).

What's been done locally is to place copies of the tarchives we use into 
our "sources" directory in version control.  So when we check out our 
local copy of OE metadata, we also get a huge, prepopulated sources 
directory.  I've also hacked all of fetching methods in our local copy 
of bitbake such that any attempt to reach outside our company for source 
produces a fatal error.

I don't like our solution because it make "mrproper" a problem and we 
have no "mrproper" of our own.  I think a better solution would have 
been for us to create a local repository aside from our source control 
system.  Then people would check out OE metadata and in the process of 
building, they'd fetch from the local repository.  But that would still 
require hijacking the component URL's, which is ugly.

As a general solution, I think OE needs to support a chain of such 
repositories and I think the OE project itself needs to create and 
maintain one.  The only way to be sure that a tarchive will be available 
is if you own and manage the repository yourself.  There's precedent for 
this - debian source packages encapsulate the upstream source so that 
the source archive is complete on it's own.  This means that the debian 
repositories each contain copies of the upstream tarchives and access to 
the upstream repositories only need to be accessed by debian maintainers 
when creating packaging for a new version.

--rich