Greetings and a General Cleanup

M.Canales.es wrote:

> The new jhalfs code may be something totally different,
thus the
> discussion is open to any one that would expose thier
point of view.
> 

Totally different. Does this mean that the C++ route is
acceptable? I take 
that for granted. How much of the original script code would
be used in that 
setting? You decide that since my approach since the
principle is: no other 
dependency other than a compiler.

> The prominent goal of the LFS Project is to create
educational books about
> how to create Linux systems using source code. Any of
the books should be
> view as a distribution but as a guide.

Not a problem. Optional sections in the layout could be of
use to more 
advanced users. If that is not a main goal and it seems it
is not, I am 
certain that it could be a nice feature to be offered by
yours truly who is 
actually desiring such an option. The entire deal is
building the toolchain 
correctly, either the LFS or the diy-linux way. There is no
need for the tool 
to be hard - locked to LFS.

> To create distribution systems from LFS books is for
the readers. And here
> is
> where the ALFS Project at a whole, and jhalfs in
particular,  could have
> something to say.

I am interested in automation. Extreme, powerful, automation
that puts 
everything else into the sweet embrace of Oblivion (polite
and constructive 
comment  ).

> To change the books sources to allow a better
automatization and
> customization of a concret book version is a
desiderable goal for the ALFS
> team, but is something that need be discussed and
decided by all editors
> and the community. We, as jhalfs developers, can't rely
our work on
> hipothetical books changes that may no occur.

There is no common way of writing the books if i am _not_
mistaken. I am not 
referring to the xml schema used, but also in the way
XQuery, XPath, XPointer 
and other X - candy are used in different settings. The
single rewrite could 
involve a more unified view of what to use and what no to
use in various 
settings, in a more predictable way. Since I do not have
anything to say, 
that can be done in auto mode via options in the tool
itself.


> But, if the planned jhalfs redesing could be
implemented, book changes
> don't must to affect the core jhalfs code, only the
code for that book
> plugin and how much customizable systems based on that
book may be.
> 

If according to your initial statement the new jhalfs code
may be entirely 
different, then what you really want  to say is that you
need to make sure is 
that you can build older versions of the books. The offered
solution should 
be completely agnostic, so what could be done is that there
can be preconf 
files that only touch sections of the bash output after
things are processed.

I do not see backwards compatibility as a problem.

What you need right now is to see a prototype that builds
the system the 
intended way. Then add ins are to follow to that. My own
work after the 
prototype is to be focused on making the output code
flexible enough to 
create package management and build an lfs core as an
example using rpm, deb 
or <put worst nightmare here> via such a
"plugin" structure. That said, and 
by offering all code under header files, one may choose how
to develop 
various strains of the tool. This way nobody gets away from
the educational 
side.

I have to say though, that my personal goal is far from
educational only. No 
harm done if that is to be kept separate and free for any
other re - 
implementations or ex novo implementation of the
LFS/diy-linux idea. If 
things are not accepted by a board of elders, there is no
reason why there 
should not exist, separately. If the tool or tools are based
on a common set 
of libraries, it is easy to build anything custom made.

That said I will work on a prototype using some of the
header files this 
weekend, concentrating on the current _stable_ version of
the book. You will 
only be seeing a single bash script, coming out of the
processing binary 
tool, compiling the entire system and configuring it.
Nothing else is to be 
presented for the sake of simplicity.

Do also take under consideration that binary code must be
safe code, but also 
extensible code. It is not like developing things in the
bash way where you 
add things along the way the "hackish" way. Either
you provide a layout and 
plan on what things need to be done and the extent of the
extensibility from 
the beginning or you pay the consequences later.

> To change the books sources to allow a better
automatization and
> customization of a concret book version is a
desiderable goal for the ALFS
> team, but is something that need be discussed and
decided by all editors
> and the community. We, as jhalfs developers, can't rely
our work on
> hipothetical books changes that may no occur.

In anycase, i can keep the optional material i need separate
and use the 
unlicensed from the community edition to substitute my
current stable and 
operational distribution environment If I desire to do so.
You only need a 
prototype for working out your side of the details, but as I
said, whether 
the book changes or not, it can be made to change
automatically, so that it 
behaves as it should for personal purposes.

Take the best from everyone. "No rules, is the
rule", meant in the polite and 
constructive way.

Thanks for responding and commenting as always. Keep up the
good work. You 
will get the prototype in a couple of days tops.

George M.

-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page