[RFC] The Future of the ALFS project

Kendrick alfs at linux2themax.com
Tue Feb 28 16:51:13 PST 2006


M.Canales.es wrote:

>El Martes, 28 de Febrero de 2006 19:20, Jeremy Huntwork escribió:
>
>  
>
>>Did I read you right, though, that you don't think a new alfs tool is
>>necessary?
>>    
>>
>
>I see some different tasks here:
>
>1) *LFS commands generation. nALFS uses hand-edited XML profiles to do that. 
>jhalfs extract automatically the commands using XSL, but work is in progress 
>to use a pure bash parser. Plus, a C parser is also under development.
>
>  
>
I think the issue is getting a tad confused here.  As per email around
11/25/2005 1:07 PM "SUMMARY: alfs direction"
we werent wholy intrested in xml so 1 is moot.  The structure of
profiles afaik has not been decided fully yet.  I would think that its
possible to incorperate jhalfs' method of auto generating sections to be
used in a larger pick n choose profile creation.  (ie like any distros
check the software you want to install,  then the installer here alfs
would setup exactly what you need.  clfs or hlfs or some specific
predefined base build then go for your blfs package sorts which would
cary forwards any special build cases like the cross builds.  another
reason for not jhalfs is the ability to remotly control 1 or 100 system
build's remotly.  also the discussion of having alfs be able to continue
to be used for maintance after said systems are built.

>2) Automatized *LFS builds. That is what currently do nALFS when using an *LFS 
>profile. Has been proved that jhalfs can do that task also, at least for 
>{C,H}LFS builds. IMHO, having a way to automatize the build extracting the 
>commands directly from the book's sources make useless to maintain a set of 
>*LFS profiles.
>
>  
>
2 also falls in with  some of 1's  new/added features for ALFS not
nALFS.   If i recall properly there was also some talk about a profile
snipit repository going around so that primarly blfs things could be
specificly setup and shared.  ie the ldap/krb5/smb/apache combo
specificly for replacing a pdc in windows could have its own specific
snipit that configured and made the whole kitten kaboodle in 1  section
taylored specificly for the intracies of that item.  another snipit
could be krb5/ldap/sasl for a email program so you could have outlook
like features setup with your address book and imap mail.

Talk for blfs side which couldent be properly done till ALFS was built
aka v2.0  was dependancy tracking so when you chose certin items it
would reorder the build process so that all optional programs would be
built before that and would add any required pieces to the list.  afaik
jhalfs wont be able to easily or posibly ever properly support that kind
of feature unless you manualy start editing ALOT. 

>3) Administrative tasks. Using local profiles nALFS can be used to automatize 
>several system administration tasks. jhalfs could do that also creating a 
>separate module.
>  
>
discussed earlier.  more rebust system for centralised administration
and upgrading.

>4) Remote builds/administration. That is what is supossed that the new alfs 
>server/client tool should to do, using nALFS, jhalfs or anything else as a 
>backend.
>
>  
>
alfs is suposed to come at it in a totaly different method then nalfs
thats why afaik the nalfs code is at bugfix only status now.  alfs was
suposed to be beyond just a rewrite but the next generation of this
idea.  we tried xml and decided that didnt work.. now we try ...   we
are aslo changing requirements some and getting closer to gerards long
term goals.




More information about the alfs-discuss mailing list