[RFC] SRS Section 2

James Robertson jwrober at linuxfromscratch.org
Tue Feb 1 20:07:07 PST 2005

Hui Zhou wrote:
>> 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 be.
> 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?

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.  The 
purpose of the DTD is to create a symmetry between package build 
commands, package meta-data and other attributes in one "profile". 
nALFS is the most complete tool based implementation of the ALFS DTD and 
so should the new alfs tool as well.  As in all XML specifications, you 
need a DTD before people can implement it.  Sharing is implied, but not 
required here.  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.
>> 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.

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

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

>>         * 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.  That is what xmllint does.  I 
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.

>>         * Downloading and checking of packages from both local and 
>> external locations.
> So http or ftp functions are necessary.

As they are today in nALFS.

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

> For serial building, dependency 
> tracking is not needed. 

But that is not the point.  We rarely do a serial build.  The main point 
of the tool is to help maintain LFS boxes over their full life cycle, 
not rebuild all the darn time.

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

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

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

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

I did not say it was un-hackable.  That has absolutely nothing to do 
with it.  The point is we have one server and one client that we provide 
(well maybe two clients - one for console/command line and one for X). 
If someone down the road wants different client (say to run on CDE to 
even windows for that matter) they can by following the spec in the SRS. 
  Take FTP for example again.  There a ton of FTP client/server 
implementations out there, but every single one of them does essentially 
the same thing no matter what platform it runs on.  That is the power of 
the spec that the implementations were written from.
>>         * 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.


More information about the alfs-discuss mailing list