alfs Requirements [Was blank]

Jon Herron leftturnsolutions at yahoo.com
Tue Oct 21 11:04:44 PDT 2008


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 <thomas at equinox.homelinux.org>
> To: alfs-discuss at linuxfromscratch.org
> 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



      



More information about the alfs-discuss mailing list