alfs Requirements [Was blank]

George Boudreau georgeb at linuxfromscratch.org
Mon Oct 27 12:52:28 PDT 2008


Jon Herron wrote:
> I've been spending the last couple days reading through the LFS book again, 
> using jhalfs, doing manual installs, etc.  Upon reading the book again I was 
> reminded that concurrent building is not a good idea, so I'm going to trust the 
> authors (who undoubtedly know more about this than I do) and go ahead and 
> nix my original thoughts on adding that bit of functionality.
> 
> Also it seems that any sort of package management is generally frowned upon, 
> which after giving it some thought I can see that side of the coin as well.  With 
> all that being said, I guess I am no longer very clear at all on what would be 
> gained by redoing jhalfs - which from everything that I can see works well, each 
> time I left it to run over night I was greated with successes in the morning.  I 
> agree that for what it does it does it well.  
> 
> Perhaps a dependency on xsl/xsltproc could be removed, but then again xsl 
> was designed with transforming xml into another format from the start.  
> Perhaps a separation of the backend from the front end could be done, to 
> allow for controlling the build from another machine, but then technically speaking 
> ssh or a remote X session could do the trick as well (assuming the host machine 
> supported such actions).
> 
> I think LFS et al is a great project, and would love to help out in some way if 
> possible, but after researching it seems that jhalfs does a pretty good job for 
> what it does.  Am I missing anything that others might have seen?

   As one of the two authors of this code, Manuel Esparcia being the 
other, I encourage suggestions. There have been numerous high quality 
suggestions made in the past and most have been incorporated into the code.

   The last major change to jhalfs was my introduction of the menu 
system  borrowed from Busybox. Since then the only work being done is 
adapting the code to and book changes in {C,H,B,L,}FS.

   That being said there is an experimental branch in the svn repository.
svn co svn://svn.linuxfromscratch.org/ALFS/jhalfs/branches/experimental 
jhalfs-experimental
created by Manuel that used xml to define private/custom packages. I did 
some testing and it works but could use some more exercise.  This branch 
may never make it to public release but you never know.

   One weak point in jhalfs is the progress bar. It is only a fancy 
timer and does not display the percent completion.  True progress would 
be based  on SBU calcs for each package. This idea ranked at 99 on the 
todo list and eventually became covered in dust. There may yet be 
interest in such a mod. (nudge,nudge)

   As I mentioned, suggestions are encouraged and suggestions with 
debugged code are usually welcomed with open arms.


   regards
    George Boudreau

>  Thanks,
> 
> 
> Jon Herron
> 
> 
> 
> ----- Original Message ----
>> From: Jon Herron <leftturnsolutions at yahoo.com>
>> To: ALFS Discussion and Development List <alfs-discuss at linuxfromscratch.org>
>> Sent: Tuesday, October 21, 2008 5:58:33 PM
>> Subject: Re: alfs Requirements [Was blank]
>>
>> I'm not completely sure this would change the fundamental processes and 
>> philosophies of LFS, since no one is required to use the automated build 
>> system, use the dependencies, etc.  However if this is the case, and there is 
>> no real new functionality that is desired over jhalfs - perhaps there is not 
>> much 
>> need to do an alfs project from scratch?  I guess it's possible this is why the 
>> project never took off years ago?
>>
>> Thanks,
>>
>>
>> Jon Herron
>>
>>
>>
>> ----- Original Message ----
>>> From: "Spahn, Daniel" 
>>> To: ALFS Discussion and Development List 
>>> Sent: Tuesday, October 21, 2008 5:09:59 PM
>>> Subject: RE: alfs Requirements [Was blank]
>>>
>>> It sounds like this involves drastically changing most of the fundamental 
>>> processes and philosophies of the LFS project. I would suggest, that if you 
>> want 
>>> to have automated builds with package management, that you look at Gentoo 
>> Linux. 
>>> I has all this in place, and might suit your needs better than LFS. If you 
>>> wanted to stick with LFS, you could also get some ideas from the Gentoo 
>> distro. 
>>> It's been my favorite since I began learning Linux.
>>>
>>> Daniel Spahn
>>>
>>> Computer Systems Manager
>>>
>>>
>>> -----Original Message-----
>>> From: alfs-discuss-bounces at linuxfromscratch.org 
>>> [mailto:alfs-discuss-bounces at linuxfromscratch.org] On Behalf Of Jon Herron
>>> Sent: Tuesday, October 21, 2008 4:58 PM
>>> To: ALFS Discussion and Development List
>>> Subject: Re: alfs Requirements [Was blank]
>>>
>>> I agree its a far reaching goal, but I do think the benefits could be
>>> huge, assuming of course the dependencies could be properly
>>> maintained.  Perhaps a first step would be to keep the current book
>>> intact, and list "lfs" as a dependency for another application that the
>>> user wants to fetch and build for instance.
>>>
>>> On a side note, if dependencies were introduced into the current book,
>>> then one could theoretically initiate more than one build paths
>>> concurrently, in hopes of reducing overall build time (at least for certain
>>> portions of the build process anyway).
>>>
>>> Thanks,
>>>
>>>
>>> Jon Herron
>>>
>>>
>>>
>>> ----- Original Message ----
>>>> From: Mike McCarty 
>>>> To: ALFS Discussion and Development List 
>>>> Sent: Tuesday, October 21, 2008 2:11:25 PM
>>>> Subject: Re: alfs Requirements [Was blank]
>>>>
>>>> Jon Herron wrote:
>>>>> 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.
>>>> [...]
>>>>
>>>> This is a laudable goal, but incurs the necessity of
>>>> adding dependency information into the book, unless
>>>> one only wants to build the "minimal system". If the
>>>> work is done "right", then additional packages not in
>>>> the "minimal system" could also be built using the
>>>> same tool, just with different books.
>>>>
>>>> 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!
>>>> --
>>>> 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
>>>
>>> -- 
>>> 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
> 
> 
> 
>       




More information about the alfs-discuss mailing list