alfs Software Requirements Specification

Version 0.1

Jamie Bennett

Matthew Burgess

Jeremy Huntwork

James Robertson

This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/2.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.


Table of Contents

1. Introduction
1.1. Purpose
1.2. Intended Audience
1.3. Scope
1.4. Product Name
1.5. Definitions, Acronymns, and Abbreviations
1.6. References
1.7. Overview
2. Overall Description
2.1. alfs Functions
2.2. Similar Systems
2.3. alfs Implementation Highlights
3. Specific Functional Requirements
3.1. Functionality
3.1.1. Profile Validation & Processing
3.1.2. Conditional Execution
3.1.3. Package Management Functions
3.1.4. Logging
3.1.5. Split of Front End and Back End
3.1.6. General GUI Features
3.2. Usability
3.2.1. Internationalization
3.3. Reliability
3.4. Performance
3.5. Supportability
3.6. Design Constraints
3.7. User Documentation and Help System Requirements
3.8. Purchased Components
3.9. Interfaces
3.9.1. User Interfaces
3.9.2. Hardware Interfaces
3.9.3. Software Interfaces
3.9.4. Communications Interfaces
3.10. Licensing Requirements

Chapter 1. Introduction

1.1. Purpose

This document provides a functional specification for the software tool “alfs

1.2. Intended Audience

This document is targeted toward users and developers of the “alfs” tool.

1.3. Scope

This document covers the high level descriptions of all the functionality that the “alfs” tool will provide. The scope of this document will be limited to describing what features will be made available, and therefore will not go into detail on any specific programming languages or development tools.

1.4. Product Name

The tool is called “alfs”. It is important it be written entirely in lowercase to differentiate it from the project name it is a part of (ALFS).

The project is the tool and the tool is the project, so the name should fit inside this idea and is why the name “alfs” was chosen.

1.5. Definitions, Acronymns, and Abbreviations

ALFS

Automated Linux From Scratch an open architecture of automating the build of an LFS system using an XML based profile.

XML

Extensible Markup Language (XML) is a simple, very flexible text format that is playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere. [1]

Client/Server

A model of computing architecture where a component application runs on one computer and another runs on a remote server computer.

1.6. References

1.7. Overview

alfs” is a tool that is used to simplify and automate the tasks that installing and managing software packages on a Linux system require. Its primary goal is to automate the LFS build procedure. Using a standard documented protocol, “alfs” will accept instructions, validate them, and carry out the specific tasks that correspond to these higher-level orders. “alfs” will then report back on the outcomes of its actions.

Chapter 2. Overall Description

2.1. alfs Functions

alfs is designed to be the most complete implementation of the ALFS schema syntax specification. It is designed to support complete automation in the creation (build) of Linux From Scratch systems. The ALFS schema is an XML specification that handles the outline of a procedure to be processed by the application. This outline is referred to as a profile. Each profile can be a small set of commands for basic tasks or a large set of commands to build an entire system including all LFS and BLFS packages. When alfs reads a profile, it parses the XML into internal command structures and uses its own library of internal shared objects to perform the actual work. alfs will not "reinvent the wheel" so to speak with regards to basic system commands like make, or cp. The shared objects are wrappers and translators for alfs to use to take the XML profile and run system commands.

alfs will also support an extensive logging XML schema. This new schema is designed to provide a large amount of logging facilities that current Linux systems support, but not in one place or within one tool. Most Linux users must use Bash shell scripts or other wrapper type scripts to pull these tools together to perform debugging, troubleshooting or comparative analysis of a build.

2.2. Similar Systems

alfs is the natural successor to nALFS. It will provide backwards compatibility but with extended, optional, functionality. alfs can be used as a direct replacement for nALFS. It should be noted here that alfs will be a complete rewrite of nALFS.

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.

  • Validation of profiles before any other actions take place.

  • Downloading and checking of packages from both local and external locations.

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

  • A comprehensive and informational logging system.

  • A package uninstallation feature.

  • Allow support for different clients.

  • Ability to handle conditional executions.

Chapter 3. Specific Functional Requirements

3.1. Functionality

3.1.1. Profile Validation & Processing

alfs” will fully support both XML profile validation and processing. Validation is the method by which an XML document (in our case a profile) is proved to fully conform to the “alfs” XML Schema and is also therefore well-formed XML. Processing is the method by which a system takes a valid XML document and separates it into useful pieces. “alfs” needs both fully valid XML profiles and powerful processing capabilities to function correctly. “alfs” will support both GUI and command line support for validating a profile.

As part of the validation process, “alfs” will also support the capability to check all packages referenced in a profile against their md5sums before build time.

3.1.2. Conditional Execution

To make “alfs” the premier LFS build tool, there has to be a way to handle conditions. Not every system is static and if the tool is going to be able to handle cross-building and other advanced features, then conditional execution is a firm requirement.

3.1.3. Package Management Functions

alfs” will support basic package management type functions. These will include dependency resolution, uninstallation, reinstallation, proper umask support, etc. The GUI will also support a feature to allow a person to query on what is installed on a system, look at dependency trees for a certain package (e.g. what has been installed and what needs to be installed), and provide full details on a package's installation.

3.1.4. Logging

As mentioned above, “alfs” will support logging the actions carried out during the installation of a package. The logging facility is geared towards the package management type functions, but also lends itself well to gathering details on SBU data, iterative comparison of builds and other such things that LFSers are interested in. The idea of the logging facility is to provide a single source of log type data from an entire build process. The logging facility must also support being able to compare different installations of the same package.

3.1.5. Split of Front End and Back End

alfs” will support a seperation of front and back end. The back end (daemon) is the process that does all the hard grunt work and the client (user interface) is just a smaller application that connects to and manipulates a running daemon. The “alfs” daemon will run on the target box (i.e. the one that you want a new LFS system to be installed on). The daemon will run as a service on a box and will have access to stateful information like profile logs, XML validation and processing code, etc. It will not provide a GUI.

The front end will provide a user interface. It will connect to the daemon (either on the same box, or from a remote one). It will be responsible for telling the daemon what profile to load and what to do with it (e.g. validate it, run it, select only a section to run, look at and analyze a log, etc.)

For the implementation of a front-end/back-end architecture, a clearly defined and supportable communication protocol is required. The only requirement is that it needs to be one in use today in the rest of the world. We do not want to create our own when so many already exist to choose from.

3.1.6. General GUI Features

  • Marking (highlighting) different interesting elements.

  • Support for interactive commands in <execute>

  • Enumerate all screen parts for coloring

  • Support for configuring colors

  • Progress indicator when downloading files

  • Command for checking archives and <unpack>'s URLs

  • Performing an action on all marked elements

  • Editing and reloading .nALFSrc from the program

  • Flag to silently ignore failure

3.2. Usability

3.2.1. Internationalization

The LFS community is made up of many people from many nationalities. “alfs” will support displaying messages to the user in their native language.

3.3. Reliability

3.4. Performance

3.5. Supportability

3.6. Design Constraints

3.7. User Documentation and Help System Requirements

As with any good application, documentation and help facilities will exist for alfs. The following documents will be made available to users:

  • alfs schema guide

  • alfs-ui user guide

  • alfsd user guide

  • lfs developers' guide

3.8. Purchased Components

alfs” is an open-source tool and as such will use absolutely no purchased components. Everything that alfs will need is already available in an OSS format.

3.9. Interfaces

3.9.1. User Interfaces

3.9.2. Hardware Interfaces

3.9.3. Software Interfaces

3.9.4. Communications Interfaces

3.10. Licensing Requirements

alfs” will be licensed under the GPL.

All of alfs' documentation will be licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License ( http://creativecommons.org/licenses/by-nc-sa/2.0/).