[RFC] SRS Section 2

Hui Zhou zhouhui at wam.umd.edu
Tue Feb 1 20:38:29 PST 2005

On Tue, Feb 01, 2005 at 10:07:07PM -0600, James Robertson wrote:
>A short history lesson may be in order.  Before there was any tool, 
>there was the DTD spec.  We are currently at version 3.1 of the spec and 
>what it supports in a profile has progressed a lot over the years.  

As I hinted, I realize this history.

>  If we write the SRS correctly, anyone can take it and 
>write their own implementation of alfs if they want to.  That is the point.

or any interested coder hates that dtd and avoided contributing to 
alfs. Anything have too blades.

>>>alfs will also support an extensive logging XML DTD. This new DTD is 
>>Logging can be single most demanding job for the tool. Generally, a fast 
>>and lossless way of putting data down is the only and key requirements 
>>for logging. Look around all the packages, do you find any other package 
>>that inserts complicated format on logging data? Spend too much time 
>>organise logging data can drag the server down, no question.
>>I propose just dumping raw log data and spent effort on a seperate log 
>>analyser to do whatever job that one wish.
>No, logging is more than that.  Again we want a lot more data and 
>meta-data on a package's install that just compile logs.  Anyone can do 
>that.  XML or a RELAX-NG schema is needed here, especially for parsing.

I am having trouble to sense what is on your mind. Do you mind list 
the type of data/metadata that needs to be logged? And why they need 
to be in XML or even RELAX-NG is needed?
>>>2.2 Similar Systems
>>>alfs is the natural successor to nALFS. It will provide backwards 
>>>compatibility but with extended, optional, functionality. 
>>One way to do it is implement a profile translator seperately, and go 
>>ahear implement the new tool without restrictions.  
>Why, not necessary.  An XML profile is an XML profile based on a DTD or 

A profile is an instruction set that a tool can used to do something. 
By nature, it doesn't have format yet, not to mention DTD. Trying 
jumping out of boundary that we have to use the old alfs dtd to look 
at this thread. You can jump back after that.
>>>2.3 alfs Implementation Highlights
>>>alfs will support the following concepts :
>>>         * Complete separation of a backend server daemon which carries 
>>>out the specific tasks and a frontend client that initiates the 
>>    The central job of alfs is profile, schedue and status maintainence, 
>>whether client or server takes care of this need to be specified here.
>????? = I do not understand this statement.

It's being discussed in another thread now.
>>>         * Validation of profiles before any other actions take place.
>>    What's the point of validation? The only matter is whether the tool 
>>can understand the profile or not. Is there any way to validate whether 
>>a profile is sane or insane?
>You must validate a profile to a DTD or schema before you run it to 
>ensure that it is a valid XML document.  
    I have comments on this in multiple threads now. it is not must. 
It's like one saying the man must be a certified plumer to attach my 
faucet. At least for me, as long he does a good job, I don't care the 

>also wanted to see the ability to "fake" parse and run a profile to 
>ensure that the commands are sane.  At least to ensure that all packages 
>that the profile asks for are present and other up front checks.  I have 
>suggested a "configure" script of some kind before.  Maybe this can be 
>part of the client.

That is possible, not without slight complication though. Only to the 
extent of validating packages though. To test configure, it will sure 
to fail for lfs at least, as the dependency does not get installed in 
the fake run.
>>>         * Dependency resolution to ensure a package never gets 
>>>installed unless it has its dependencies satisfied.
>>     So the profile need dependency info. 
>Yes, again the need for XML comes up.

Well, :), totally un-related.
>>For serial building, dependency 
>>tracking is not needed. 
>But that is not the point.  We rarely do a serial build.  

We only does serial building so far :) Check Gerard's reply.
>>The tool just runs the building instruction 
>>sequentially. If there is dependency conflict, it is the profile 
>>writer's fault. There are millions of way for a profile writer to make 
>>mistake, don't try to correct them by the tool as the job is huge.
>>     With the dependency info in the profile, does that mean the tool
>>should be able to do parallel building/installing? Why not?
>You are missing the point.  We want the power to handle dependency trees 
>and pick from them (a client function for sure - the grunt work to 
>create the tree is done on the server and sent to the client for 
>display).  Don't completely place the burden of profile sequence on the 
>profile writer's shoulders.  If dep is handled right, I should be able 
>to build a library of single full XML files.  I could then create 
>"profile" that installs GNOME that just has all the packages dumped 
>together.  Load the thing in the server and press GO.  The server 
>handles the rest.

Ok, I see you are talking about blfs building. Your statement 
generally seem alright. Well the dependecy most likely still have to 
be specificaly input by maintainer. Automatic dependency more than not 
won't work. Todd Benett is quite strong on that.
>>>         * A comprehensive and informational logging system.
>>     Can be achieved by seperate program. The question is does the tool 
>>need the logged data to run successfully. If not, don't make things 
>>complicated. The tool just need make sure no logs is lost even in the 
>>case of power failiure.
>We need this for conditional exec probably, for package manager type 
>functions, for error checking and correcting of builds (think 
>lfs-hackers), {B}LFS book maintenance (think SBU's, HDD space used, 
>etc).  All sorts of stuff.  The logging DTD is been a long time in the 

Too abstract to comment.
>>>         * A package uninstallation feature.
>>     That's tough. That may bring the tool close to a full fledged 
>>package manager. It can be a huge task.
>>     Is there any possible profiles that builds a system need 
>>uninstallation of some other package? If not, make it a function of a 
>>complete seperate program. As all the installation data is logged and 
>>hopefully is analysed into a data base, it is not difficult to make a 
>>program to do uninstallation if dependecy is just ignored.
>Yea, but you can't way it is not WAY cool!

Well, I agree the cool way. I won't should it lightly personally.

>>>         * Ability to handle conditional executions.
>>        no comment.
>You have got to be kidding - no comment!  I will go on the record as 
>saying that this is a long time coming as well.

No comment on the ABOVE sentence. For the ohter sentences, I did. 
I guess I should just delete the quotes. My bad. 

Hui Zhou

More information about the alfs-discuss mailing list