I have been tossing the idea around of using an intermediary format, which is derived from the lfs sources/book, as I feel too that using the sources dierectly this is the way to go. Not only does the automated tool not have to incur maintenance when the book is updated, but the automated tool can also serve as a unit test of sorts to make sure the userinputs defined in the xml sources are correct. Naturally translating from sources to another format could negate the unit test theory in its purest form, but what could be gained is a "package" description of sorts that allowed for other applications to be installed during an lfs/blfs build. If I recall correctly this exists in jhlfs and I think it would be a great feature to keep.
On a slight tangent, if an intermediate format for package descriptions did exist, with a format for describing dependencies, build params, etc, users could contribute these back to the lfs/blfs/customlfs communities. These package descriptions could be used by other users, creating fully custom builds that might be of more use to the everyday user. Just a thought. If I'm way off my rocker let me know. I personally enjoy python - the main reason I asked the question was I noticed on the livecd that currently gcc, perl and tcl are available (if I missed a language please correct me). I did not know if adding using another language was a deal breaker, since it would need to be added to the live cd. Granted if using a regular distro as the host system this is probably not a big deal, not sure if the livecd is the more popular option for users or not. With that being said - I didnt want to start on a new alfs in a language that would never make it onto the livecd for one reason or another. Also not matter what the language, the code should be readable and maintanable for sure. Thanks, Jon Herron ----- Original Message ---- > From: Thomas Trepl <[EMAIL PROTECTED]> > To: [email protected] > Sent: Tuesday, October 21, 2008 1:36:34 PM > Subject: Re: alfs Requirements [Was blank] > > Hi all, > > allow me to add my two cents here. I take this thread as some "collect ideas > and directions for a new {jh,}alfs". If this is not the case, than sorry, I > did missunderstood - ignore the rest. > > I would like to add that one of the most disadvantages of the early alfs > project was that there was a need to generate a seperate set of files where > alfs can work on. This was fixed in jhalfs and therefore it was pretty easy > to use. Even on own deviations from the "standard" book (something like > uncommited version upgrades or so). For me, this is a plus when the tool can > directly act on the books sources, just as Jeremy previously said. > Or, what about a new form of package description files where a {jh,}alfs > program can easily act on and the books source (or major parts of it) could > be created out of them. This could be sets of files which are more > package-management-optimized. Dunno if this last sentences does make sense at > all. > Anyway, what I would say what is important for a new alfs is: Act directly on > the primary sources. > > Now, the language a new tool may be written in. Using such a tool does not > raise the question in what language it is written and how does the output > (commands that will be executed) does look like. The prime focus should be > the usability. Btw, the UI of jhalfs is by far quite enough for such a kind > of tool. But from a development perspective, Python may not be the worst > choice. It seems to be very self-explaining and new developers seems to be > productive quite quick. But I also agree to what Bruce has said: The ease of > viewing etc.etc. is quite important, but if you write it in a readable way, C > could match that too. But at the end of the day it does not really matter as > long as the prerequisites to run the new tool are not to big. Just "download, > unpack, cd into, make and run" is what it should look like and this works on > full featured distros as well as on a quite newly set up LFS-system. > As a result, execution speed is by far not relevent for such a tool but the > ease of using the product but also the ease of develop it. > > -- > Thomas > -- > http://linuxfromscratch.org/mailman/listinfo/alfs-discuss > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/alfs-discuss FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
