Hi Charles,
I guess that's as easily done with this scheme as with any other (provided you have write access to CVS if you want to make things public). I rarely ever have a version of conf/sources.cfg that looks exactly like the one in CVS (that's what CVS is best at, afterall - merging upstream changes into a locally modified file. As long as one remembers not to add stuff to the end (since that causes conflicts if changes are made to the end of a file upstream as well), everything should be fine).I'm looking at this from the perspective of a 'power' end user, who would like to tweak some things, but be able to easily stay current on files I choose not to modify. With all package/source statements in a single big file, it seems like it would be harder to use CVS or other versioning software to track changes I've made to the release versions. Examples of things that it would be nice to be able to setup:
- - Add package(s) (ie: current vim, rsync, qmail discussions)
- - Customize package(s) (ie: unique compile-time options or similar)Well, as long as you don't want upstream changes to be integrated in your modified version (see below for that topic), you can do that by separating the sourcing from the build - run "buildtool.pl source packagename" first, make your modifications, run "buildtool.pl srcclean packagename" (to make sure all your changes are taken into consideration, especially if autoconf is incolved).
After that, run "./buildtool.pl build packagename", the sources should be compiled including your changes.
But this approach doesn't work for integrating upstream changes into your setup.
- - Re-target downloads to a local repository or mirror (to verify completeThat should actually be possible, at least for the packages we've cleaned up already. Once everything is cleaned up, there should not be any redundant server definitions - so changing the cvs-sourceforge server definition in conf/sources.cfg to point to your mirror should make every package definition use that mirror server (at least, where cvs-sourceforge is used, and where we've removed all redundancies - if you spot a package where this isn't the case, please let us know).
independence from SF or leaf-project.org, and to control exactly which
version(s) of packages are used for an 'in-house' release).
I presume you're referring to something like making changes to a buildtool.mk file locally, and having upstream changes be merged into your files upon request (just like it's done with conf/sources.cfg). Unfortunately that's not possible (I've cursed that a couple of times too), at least not within buildtool (since buildtool simply downloads files via wget).- - Easily update a modified project to use new data from the SF CVS archives if/when it becomes available
What _is_ possible (even though it requires a little more manual work) is to keep a checked out copy of our "apps" tree (where most of the stuff comes from anyway), make changes there and then manually copy your changes to buildtool/source/packagename/
I admit it is cumbersome and somewhat error-prone, but that way one can maintain local modifications and still benefit from upstream changes.
Well, I don't claim that those workarounds are simple (or that they should be obvious to somebody trying to learn to use buildtool). Buildtool wasn't designed knowing all the requirements that would come up with more and more people using it (and that's even more true for buildpacket.pl, which started out as a simple 20 line script to automate the repetitive and error prone task of putting stuff into lrp files) - it developed in a somewhat evolutionary process, and it shows.It may be possible (or even easy!) to do this with the current config file, but I didn't immediately see how...
Many things aren't terribly consistent, and we'd probably do quite a few things differently, if we were imlementing buildtool/buildpacket knowing what we know now.
But whatthose two tools do is to automate building a source (and an lrp package with buildpacket), thus enabling more people to compile the programs, letting the Bering uclibc developers concentrate more on getting the compile settings "just right" and making updated to new upstream versions (of an application) much easier. Ideally, all that is needed to update to a new version is to replace the filename in buildtool.cfg, change the directory name in buildtool.mk and rebuild.
I hope that clarifies a bit.
Martin
------------------------------------------------------- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click
_______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
