-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Martin Hejl wrote:
| Hi Charles, <snip> |> 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 | 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. | 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'm less worried about the packages/sources issue than splitting out the various packages (more below).
| 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). | |> ...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... | 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.
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)
- - Re-target downloads to a local repository or mirror (to verify complete independence from SF or leaf-project.org, and to control exactly which version(s) of packages are used for an 'in-house' release).
- - Easily update a modified project to use new data from the SF CVS archives if/when it becomes available
It may be possible (or even easy!) to do this with the current config file, but I didn't immediately see how...
- -- Charles Steinkuehler [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFCQGbJLywbqEHdNFwRAhHgAKDMK9OuC5foNly2WNh8c5nCP8h5nwCggd5g PDrVbFern39w4LixRUvqPsg= =UKhW -----END PGP SIGNATURE-----
------------------------------------------------------- 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
