alfs Requirements [Was blank]

Jon Herron leftturnsolutions at
Tue Oct 21 07:26:12 PDT 2008

Mike -

  I agree that having a nice front end to walk you through the build process would 
be a big win for a majority of users.  I for one tend to prefer a command line 
interface, but to me this is a great example for why the separation of the back end 
from the front end would be a big win.  

  A dependency database for packages would be a big plus as well, as long as 
it was properly maintained.  I would also be interested in a way of associating 
required/strongly suggested + optional patches for a given package as well.  
Not sure if package is the proper nomenclature here or not.

  I am still gathering my initial thoughts after letting jhalfs run again over night, 
using the livecd with local lfs-sources.  One early thought I had was in regards 
to the overall run time.  I would like to explore to see if there are any aspects of 
the build process that can be run in parallel.  Whether this be compiling sources 
that do not directly depend on the previous step, or retrieving source archives 
from svn or the web concurrently.  Granted this is an early idea and might not pan 
out, but I thought it might be worth looking into, or at the very least bring up for 
discussion.  Once again I have only run jhalfs on the livecd with local sources, 
so perhaps some of this functionality is already present.

  With regards to creating a directory tree ready to be mounted, or an iso ready 
to be burnt, this would be an excellent end goal, and something that I think with 
some work would be very do-able.  


Jon Herron

----- Original Message ----
> From: Mike McCarty <Mike.McCarty at>
> To: ALFS Discussion and Development List <alfs-discuss at>
> Sent: Monday, October 20, 2008 5:30:49 PM
> Subject: Re: alfs Requirements [Was blank]
> Jon Herron wrote:
> > Thanks again, I appreciate the input.  I'll start working on the initial draft 
> and present it to the list.
> > 
> >  Thanks,
> > 
> > 
> > Jon Herron
> > 
> > 
> > 
> > ----- Original Message ----
> >> From: Jeremy Huntwork 
> [...]
> >>
> >> As far as languages go, I personally would prefer C or C++ for speed and 
> >> portability, but that's just me. I also don't like to depend on many 
> >> outside libraries or packages. Again, that's just my take on it, though.
> Requirements must be stated in terms of measurable results, not
> in terms of means. If you want portability, then that's the requirement,
> not C or C++. If you want speed, then ditto. In this case, I believe,
> execution time is going to be dominated by fetch speed (download times
> for the sources) and compile times, not by the speed of the tool
> itself.
> As it is, LFS already depends upon bash, so I see no problem
> making it use scripts. In any case so long as the build dependencies
> get fetched and built (like, say, Perl, or AWK, or whatever)
> then I don't see what an objection might be, other than build
> time for the tool. The entire build is going to take so long
> that building Perl one additional time is negligible, I think.
> What would really be nice would be some sort of front end which
> allowed selection of packages to be included (like GUI etc.)
> and which would create scripts to do the fetches and builds using
> some sort of dependency database. It would be fantastic to be
> able to run a front end, click on some check mark boxes, and
> kick off a build which resulted in an ISO image ready to be burnt
> to CD-ROM and booted, or a directory tree ready to be made
> bootable by, say, GRUB. Then you'd have a distro with source
> somewhat in the same vein as GENTOO.
> However, that's asking a lot, I know.
> Mike
> -- 
> p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
> Oppose globalization and One World Governments like the UN.
> This message made from 100% recycled bits.
> You have found the bank of Larn.
> I speak only for myself, and I am unanimous in that!
> -- 
> FAQ:
> Unsubscribe: See the above information page


More information about the alfs-discuss mailing list