Format for the future LFS

[Gerard Beekmans]

>>  This idea didn't come to fruition mostly due to server resource
>>  limitations. That problem shouldn't exist anymore nowadays.
> 
> Here I am not sure whether I agree about the reason, but this
> disagreement is off-topic for this thread.

It truly was the primary reason. The LFS server back then did not have 
enough CPU speed or RAM to handle dynamic requests like that. It took 
about 30 minutes to render one static LFS book back in those days. 
Imagine hundreds of requests a day. It wasn't going to work from a 
purely physical point of view. The idea had died with that realization.

> I want the idea to be clarified by providing samples how the generated
> content should look like, in terms of HTML layout. Such samples would
> help us classify the replaceable/optional items and thus avoid
> redesigning the generator more times than it is needed.


We don't need to worry about the physical presentation of the material 
yet. It's the lesser of concerns. One possible way is that based on user 
selection on the website it creates a custom index.xml file which pulls 
in different chapter 5/6 XML files that make up the individual 
installation pages. That would be one way to get a custom book.

The real issue at hand is how we can save ourselves a lot of time seeing 
we'll have regular package installations (what we currently have in the 
book) and the RPM/DEB/DESTDIR/etc versions. If a package changes we 
don't want to rewrite too many files and make the same changes.

Is that (partly) what you were saying? There are many questions still 
and we've started to run ahead of ourselves and trying to tackle too 
many things at once.

I'm going to be collecting Package Manager tech explanations first. It 
may not be the best place to start in the end, but it's a place and we 
need to move forward and not endlessly discuss where the best place to 
start is. That will all fall into place soon enough.

Gerard