alfs Requirements [Was blank]
leftturnsolutions at yahoo.com
Tue Oct 21 07:26:12 PDT 2008
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.
----- Original Message ----
> From: Mike McCarty <Mike.McCarty at sbcglobal.net>
> To: ALFS Discussion and Development List <alfs-discuss at linuxfromscratch.org>
> 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
> 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.
> 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: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page
More information about the alfs-discuss