Hello,

So I finally got a free evening and the energy to sit down and get 
conceptual. This is the result: 
http://linuxfromscratch.org/~jhuntwork/php-test/

Before replying about all that you see is wrong with it ;) keep the 
following in mind:

This is a rough draft! A proof-of-concept only, designed to show 
possibilities and open up discussion/ideas. Think stick-figure.

Some random notes:

  * Look out for subtle differences between architectures (notably the 
dl name changes and there's an extra command for x86).

  * The command explanations and descriptions are left out for the RPM 
pages. Partly because I wanted to focus on the showing the creation and 
use of the spec file, but also because I am uncertain at this point if 
those notes should be comments in the spec file or if they should exist 
similarly to the current book with the commands being continually 
appended to the spec file. It is my full intention not to lose value of 
the current LFS format, but rather to expand on it.

  * As it is now, the RPM instructions aren't complete. There are some 
useful (and even necessary) features of the spec file that were left out 
for the sake of quickly illustrating the potential for dynamic 
rendering. Also, the commands don't yet make use of any DESTDIR 
features, although they will need to do so.

  * The source files for the PHP are all viewable by appending an 's' to 
the end of every php url. (You could begin with 
http://linuxfromscratch.org/~jhuntwork/php-test/render.phps and work 
your way through the includes)

To briefly describe the current process, the render page sets some 
session variables based on the user's choices then includes the package 
install file which contains arrays of arrays of commands for the 
package. (This file also includes a data file which contains general 
data about the package, version, size, url, description, etc.)

To illustrate:
The $pre array contains one array for each command that is done 
pre-build, seds, patches, etc. Each of those arrays contains 2 or 3 
keys: a description of the command, the actual command to run, and an 
optional key containing a list of architectures this command applies to. 
If there is no 'arch' key, then it applies to all.

If the idea of editing the php source is scary or distasteful, it is 
totally conceivable to create a sort of Wiki interface to the pages. 
General text would be editable much like any other wiki, but items that 
are part of the core or need to be used in a dynamic way, such as 
commands or package metadata could be 'objects' with parameters and 
editable in a special way. (Not sure if I'm making this concept clear, 
but with more time or discussion you should be able to see what I mean.)

Anyway. This was a start on realizing some of the ideas presented here a 
month or so ago. I hope that we can build on some of that energy we saw 
here instead of losing it completely.

--
JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to