Hi Erich, > Thank you, the biggest problem was to find the correct place for a > module, in this case the r1000 thing. I don't know if a module sent to > contrib gets included into the lib/modules tree/tarball. Not as far as I know. Eric might be able to help with that.
> would you guys be thinking about a hierarchically flat CVS which > holds a complete tree of the development environment? I'm not sure what exactly you're suggesting - do you mean we should check in the whole /stuff/sourceforge/src/bering-uclibc/buildtool tree (including source, build and staging) from a box that has build everything available? If so, I don't understand what is "hierarchically flat" about that - but we'd surely burn a lot of disk-space on the SF servers... Or do you suggest we'd check in the /stuff/sourceforge/src/bering-uclibc/buildtool/source tree (with everything unpacked)? That has been suggested in the past (or something along those lines), since it would make it easier to see what changed between releases. But I like the "upstream tarball + patches" approach, since it makes it easier to remove a patch, once it's no longer needed. Besides, that would not fix most of the problems people have (since most of the time, they're due to incompabilities between the source being compiled, and the toolchain on the host computer). > Having read lately > about trouble getting the buildenv set up convinces me that a flat CVS > could lower maintenance effort. Possibly - at the price of adding support issues in other places (if I understand your suggestion correctly). The problems we're having with buildtool (at least the latest ones) have little to do with keeping the sources apart, and much more to do with changes in the tool-chain (ubuntu ships a different gcc,libs,kernel headers than RHEL than debian and so on). But maybe I'm misunderstanding your suggestion - please clarify if you think that might be the case. > I understand the idea of keeping the > various sources apart, but the latest development in the GPL appears to > make it mandatory to keep sources of everything anyway, so we cannot > rely on external repositories. We don't, as far as I can tell - apart from a few sources, like the kernel and gcc (I agree that we should probably keep those in cvs as well). In short, we already keep the sources of everything (minus kernel and gcc) already. > I believe it would also be easier to > handle comprehensive versioning as everything may depend on a certain > version of the development environment. Not so far (but it is a possibility this may happen) - so far, we try our best to make sure that a checkout of the buildenv for a given timestamp works with a checkout of everything else for a given timestamp - so basically, that versioning is already in place. Again, maybe I'm misunderstanding what you're suggesting - but if I'm not, it would make life harder for the people who actually use the buildenv to develop new packages regularly (since an update to cvs might break something the next time they do "cvs update"), while it would surely help those who just want an up to date buildenv quickly, to compile something. There has been work on getting a vmware (or something similar) image that provides a buildenv - would that help? I guess it's not finished yet, as always, due to the lack of extra time available. There's even been work on setting up a self-contained uclibc-only vmware image (would be cool for those troublesome sources that insist on linking against the host libs, no matter what you do), but that has died half way, due to lack of time. And basically, I don't think that's the way to go, since we should work on fixing the sources, to make them be able to handle a cross compile. In short - a lot has been tried to make the process of getting a working buildenv easier - but so far, it all died half way, before the point where it could be given to the people who are having a hard time setting up a build environment. And all that comes down to lack of manpower - if there were a handful of people working on just that task, it would be doable. But as long there's only a handful of developers on the whole project, I don't see it happen (unless somebody who really wants that fixed picks up the ball and does it). Just my thoughts - I'm not speaking for anybody but myself. Martin ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
