Hi Charles,
I see kp already responded :-)
Well, that behaviour can be changed in conf/buildtool.conf (with the "OverwriteFiles" setting). Normally, downloading files again is the smart thing to do - but unfortunately, with the download issues SF has had lately, this can also lead to corrupted archives (and errors trying to extract them later on). I guess there's no perfect solution (other than making wget download the file again and again until it thinks it got the whole file - which, as far as I know, is being worked on at the moment).| You'll have to add the new package to conf/sources.cfg like any other | - don't bother about server/network stuff - with all needed files | in sources/yourpackage it will not try to download again.
Thanks...I didn't realize it wouldn't try downloading if the files are already there.
I agree that mixing the servers with the sources wasn't a terribly good idea - but then, the "servers" in conf/sources.cfg should really only be sourceforge servers (since that's where buildtool gets the buildtool.cfg from), so that part should be fairly static.So far, the only thing that seems odd about buildtool is the centralized file with all the servers, sources, and packages (conf/sources.cfg). The files for building each package are already seperated per-package, so it seems like this should be multiple files and/or directories as well, ie:
~ conf/servers <- File with server entries ~ conf/pagkages/ <- Directory ~ conf/packages/mypkg <- Single entry ~ conf/sources/ <- Directory ~ conf/sources/mysrc <- Single entry
The split between sources and packages doesn't make much sense to me right now - mainly because the difference between sources and packages is very "muddled" at the moment (the only program that actually makes some use of that info is buildpacket.pl - so if we defined everything as "package" it would work the same way it does right now). But that may change some time soon as well (or maybe it has already, I've not managed to stay up to date with Arne's latest changes/scripts).
I guess the reasoning was to keep things simple and avoid instances where files weren't kept in sync. Plus historical reasons (things were stored in a similar manner in the original, make-based buildtool from uClibc, which we adapted to work for our needs).
I'm sure it will be at some point. But I'm not sure if keeping several small files up to date is going to be easier in the long run (not for adding/removing, but for other kinds of maintenance - new dependencies, splits of packages and so on). I guess it isn't pretty either way....but I have no idea how easy/hard this would be in perl (yes, I've fallen to the point of suggesting new features/functions w/o offering any coding assistance! :). It just seems that having to modify the entire sources.cfg file to add/remove a package is going to get cumbersome eventually...
Also, what's the preferred method to provide files for a new package so theyA tgz with everything bundled up together would work be perfect. For larger sources, I guess a link to the original source would be best (few people like having the kernel source in their inbox :-))
can be included in CVS? A tgz file of sources/pkg and a diff of
conf/sources.cfg, or some other method?
The changes to conf/sources.cfg need not necessarily be a diff (but then, creating a diff against the current version in CVS simply by issuing "cvs diff conf/sources" is probably easiest for everybody anyway).
I hope that helps. Pointers inaccurate/wrong parts of the docs are always appreciated (I just can't promise I'll fix things immediately - I'll be on holiday over and the week after easter).
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
