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.
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.
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.
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.
Based on that, I think that jhalfs is a working nALFS replacement for 1) and
2), and maybe 3). But 4) will require a new different tool.
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com
TLDP-ES: http://es.tldp.org
--
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
