[RFC] SRS Section 2
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
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
>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
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.
More information about the alfs-discuss