[RFC] SRS Section 2

Hui Zhou zhouhui at wam.umd.edu
Tue Feb 1 13:37:18 PST 2005

I like to see the list getting busy :)

Here is my comments regarding the SRS sect 2. Many points I have been 
said in other posts, repeated here so they don't seem like random 
shouts. Hope I didn't annoy too many people. If I did, it is already 
too late. Accept my apology though. :)

On Tue, Feb 01, 2005 at 11:10:53AM -0500, Jeremy Huntwork wrote:
>2.1 alfs Functions
>alfs is designed to be the most complete implementation of the ALFS DTD 
>syntax specification. 

I am having trouble of this statement. Natuarally, the function of 
alfs is automatic building lfs system acording to a predefined 
building instructions. If I am to implement it, I would define my 
profile syntax based on the tool since only actually implementing the 
tool one would know what is the most efficient syntax of profile would 

In the history, alfs dtd existed so independent implementers can share 
profiling works. And reading the history, this sharing need never 
rises. In the meantime, the alfs dtd kind of pre-requires a xml 
parsing and validating functions in the tool implementation, which 
imho, not of much necessity if no sharing is needed.

This time, we don't have a dtd yet. Do you think this statement is 
still approarate?
>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.
>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.   

>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. 

>         * 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?

>         * Downloading and checking of packages from both local and 
>external locations.

So http or ftp functions are necessary.

>         * Dependency resolution to ensure a package never gets 
>installed unless it has its dependencies satisfied.

	So the profile need dependency info. For serial building, 
dependency tracking is not needed. 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 
	With the dependency info in the profile, does that mean the 
tool should be able to do parallel building/installing? Why not?

>         * 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.

>         * 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.

>         * Allow support for different clients.
	That don't need to be specified. Did you find any server that 
is unhackable? There is a server, there will be possiblly millions of 
client in all kinds of shape to talk/hack/hijack it. The server 
defines the rule.

>         * Ability to handle conditional executions.
        no comment.

Hui Zhou

More information about the alfs-discuss mailing list