Top things to see in first ALFS

Gerard Beekmans gerard at
Tue Feb 1 10:20:19 PST 2005

On Tue, 2005-02-01 at 10:24, Hui Zhou wrote:
> I will propose one model: the server run standalone, which mean it 
> works by "alfs profile run" and it will run from start to end without 
> problem if the profile is proofed. 

I personally was more thinking along the lines of a system has an "alfs"
process running in the background that isn't doing anything.

Then you connect to that daemon with an alfs client and tell it to do
something such as run a profile (or a subsection thereof).

For instance, you can have ten machines running alfs-server in the
background idling and doing nothing. Then on your main machine where you
store your profiles you would run one alfs-client command and tell it to
run chapter 6's gcc.xml profile. The client is told which machines to
connect to and issue the build command. In this case one command like
"alfs-client -a chapter06/gcc.xml" would connect to all known systems
and run profile. One command and now you have ten systems automatically
upgraded to the latest GCC. The client would keep track of the ten
server's progresses and tell you when they are done or encountered an
error, etc.

> If alfs is developed without specific concious of package manager, I 
> quite suspect that some stage, one would call for program from scratch 
> again.

That might not be an issue. If there is proper installation logging we
have all we need. A package manager can be built around those logs. And
if more info is required, the logging component of alfs can be extended
to provide additional information (such as the dependencies involved
when building a package).

Gerard Beekmans

/* If Linux doesn't have the solution, you have the wrong problem */

More information about the alfs-discuss mailing list