On Wednesday 05 March 2008 07:52:19 Alexander E. Patrakov wrote: > [snip] > 3) How (from what form of sources) should all of this stuff be generated?
One option then: There should be a variably verbose XML - based format describing everything from different languages for the end user (internationalization is a feature I do not see quite often raised here though), different package manager selection (if in the end you decide to support multiple versions, which is one thing to consider), package metadata information. As J. Greenlees suggested on this thread, it is advisable to have your own DTD, or a set of DTDs about this. Docbook will just _not_ cut it, and it was a *BAD* technical decision that leads the team here. I am not suggesting "bad" as non functional, but "bad" as in dead - end leading due to not having these options. There are also issues on not just the format of the DTD and its "layout" though, or the CSS/XHTML combinations for viewing things right; before touching them though, it is better to focus on XML itself and one simple thing: How verbose should it be, and should you "chain" it to the needs of a particular package manager? XML in general, suits the task because of its descriptive power, its almost immediate human - readability, its by default modular nature and its transfer - medium qualities even between different applications, in a standard and predictable by all editors manner. You could for example have different XML files describing alternative components to consider during the build of a particular "stream" of the book, done by different teams of people with talents that can group together nicely targeting a single sector of their choice. There can be quite diverse processing over these in order to produce the end "monolithic" XML/package from which everything else stems for that package; and you will also need to focus on the tools you want to have for something like this. It should be the XML document format to be the logical supergroup from which the eventual PM be "fed" the info from and not the other way around. Regardless of what you choose to do in the end, there are some extra issues: 1) the freedom you wish to have over the framework for the build cycle. 2) the choice you make on how to maintain the framework for automation. 3) how to prioritize different components so that this does not blow up on your face 4) accept the fact that in this way, you need something extremely accurate because increased variables in the game mean _increased_ eventual bugs that have nothing to do with the sum of the packages as distinct software entities over the project. 5) you need steady - rate development. Steady - rate. By the time you reach (5) there is also going to be a (10). But it will be at most 10. And everything should be easy to maintain. My only concern over this is that if you only wish to go around the pedantic route, then this is an overkill. If you don't, then it is a viable alternative with even bigger long term potential than what it seems right now. > -- > Alexander E. Patrakov George Makrydakis -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
