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-discuss FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
