Am Mittwoch, 29. September 2010, 20:44:11 schrieb davidMbrooke: > On Wed, 2010-09-29 at 19:57 +0200, Martin Hejl wrote: > > Hi kp, > > > > > (btw: the issue started with DavidMBrookes question, if sources should > > > go into cvs or not? The discussion drifted away - any ideas on that > > > topic?) > > Yes, this was all *my* fault; I was hoping people had forgotten... :-)
I'm sorry to remind an ancient post :) > > I'd say yes - it will be easier that way to provide a source tarball > > (whatever that has to include remains to be seen) if it's decided we > > need to, but maybe more importantly, buildtool will not break if the > > location of a source changes upstream. As a bonus, it makes it easier to > > build things offline - just make a cvs checkout of the whole src path, > > and everything needed for building the toolchain and packages is right > > there and can be built without internet access. > > Personally I agree. On balance it seems best to "snapshot" the upstream > sources in our CVS and only refer to our CVS for source downloads. > > > I just don't know how happy SF will be, if we put tons of (additional) > > binaries in CVS. > > The 2.6 Kernel source is about 70MB and that's the biggest upstream we > have. If we provide a downloadable (outside CVS) full source snapshot > for every formal binary release (4.0, 4.1 etc.) those will be much > bigger but not that frequent. I don't think that's too bad, but then I > don't have to pay SF's hosting bills... There will be another 70MB for buildenv (mainly gcc, binutils and uclibc). I haven't checked the sources, but AFAIK linux, buildenv and shorewall are the only sources left, staying outside of our repository. I agree that having everything in a snapshot can be useful. kp ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel