[RFC] SRS Section 3

James Robertson jwrober at linuxfromscratch.org
Fri Feb 4 19:04:30 PST 2005

Jeremy Huntwork wrote:
> Ok Everyone. this is the big one. I think just from our discussions over 
> the past few days we all likely have a clearer picture of what exactly 
> it is that we're after with the new tool.

I am going to comment on my thoughts for just about every section here.
   I wanted to try and convey what I was thinking when I wrote this
section.  And as Matt has already noted - yes the sections and
boilerplate text is all based on my personal SRS template that I have
been using for years.  It is based on the IBM Rational Unified Process -
A CMM level 4 software development methodology.  I apologize in advance
for it's length

> 3.1.1 Profile Validation & Parsing
> alfs will fully support both XML profile validation and parsing. 
> Validation and parsing are two seperate things. Validation is the 
> process with which an XML document (in our case a profile) conforms to 
> the DTD properly and is fully valid XML. Parsing is the process with 
> which a system takes a valid XML document and rips it apart into useful 
> pieces. alfs needs both fully valid XML profiles and excelleent parsing 
> 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.
> See Parsing, Relax-NG and md5sums for more details.

OK, So now I know more about how the two work together and Matt's add of
processing in place of parsing seems better to me as well.  What I
wanted to convey here was that we need alfs to handle validation for us
(a mini-test like what xmllint does) to ensure that profiles are good.
I looks like alfsd will be host for the engine to do this, since it will
have to do it anyways for an actual run of a profile.  The alfs-ui will
be able to "see" a profile only in its pure XML form and cannot
parse/validate/process it.  It will require a command sent to alfsd and
a subsequent return from alfsd to see what the result is.

As for "both GUI and command line..." support, this still fits with the
client/server architecture.  The alfs-ui will have command-line support,
so sending a validation request via command line should be easily possible.

The last paragraph may be confusing to some.  What I wanted to say here
was that if the profile tells alfsd to download a package, then it
should also do the md5 sum check at the same time.  If the profile has
all the packages pre-downloaded (say in /usr/src/packages) I wanted to
be able to have the tool ensure that all the packages asked for were
there and that md5sums were ok before build time.  This was to help
alleviate some of the questions we receive on the list on the subject,
especially from folks wanting to use the stock profiles.  This may need
to be removed or amended as Kevin et all have mentioned that it should
be the profile writer's responsibility to have that done in advance.

> 3.1.2 Conditional Execution
> One of the major problems with the current nALFS is that there is no way 
> to handle conditional execution (if, then, else). To really 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 definitely needed. There is no detail page for this, just a few bugs. 
> The new ALFS DTD v3.2 that will be used for alfs will contain the 
> required elements for conditional execution and the handlers will need 
> to be built to do the work.

Some notes by Kevin fill this in nicely.  I am not sure what Hui was
mentioning or who it fits.  I can't see how if/then/else is that hard.
I have it already in bash scripts.  Why would this be hard in a profile.
If condition A = value then do step 1 else do step 2.  How is that hard?

Matt is right that we need to pull all references to nALFS.  alfs will
support conditional execution. We do need to flesh out what changes to
the DTD need to occur to make this happen.  Probably in the form of ATT's

> 3.1.3 Package Manager Functions
> alfs will support basic package manager type functions. This will come 
> mostly with the new logging facility. As such the new tool will support 
> full dependancy 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 dependancy trees for a 
> certain package (like what has been installed and what needs to be 
> installed), and provide gory details on a package's installation.
> See Dependencies for details on the dependancy feature.

Here I introduce a little more about the logging DTD.  I particularly
like the support for querying what has been installed on a box and when.
  RPM supports this and it quite nice.  It should be noted that the logs
are to be kept on the same box as the back-end alfsd daemon.  It is what
is going to be using them, not the front end.

> 3.1.4 Logging DTD
> As mentioned above, alfs will support a new logging DTD. The logging 
> facility is geared towards the package manager type functions, but also 
> is an excellent way to gather details on SBU data, iterative comparison 
> of builds and other such things that LFSers are interested in. The idea 
> of the logging DTD is to provide a single source of log type data from 
> an entire build process. The log files will support apending data to the 
> end, so that if you build a package more than once, you can see the 
> difference.
> See 
> http://linuxfromscratch.org/pipermail/alfs-discuss/2004-February/004585.html 
> for a good start of a conversation on this topic. You can also refer to 
> Logging.

As Jeremy H asked, he wants more info.  I am of the mind that the only
way to be able to handle all the things that a package manager handles
is to "know" what the state of a box is.  A package manager handles
dependencies.  To do that, it needs to know what all has been installed
already.  Hence the log.  It should say what package and what versions
have been installed and where.  I want the log to be verbose.  The more
the better in the log.  What Kevin proposed and tweaking we did on the
list from the link does a really good job of capturing a lot of
information necessary. A package manager can un-install a package.
Well...It needs to know dependency info and it needs to know what a
package installs (seen as changes to a system) to be able to roll back
those changes.  This is a tough one to catch because if a package runs a
sed on a text file, I am not sure we can capture that in the log to be
able to roll the change back.  I'll leave that up to smarter
                   folks.  Also, if you try to remove a package that in
the middle of a dependency tree somewhere, you should get an error.  The
log should have the dependency tree in it when a package is installed
(taken from the profile).  The way a profile is not required to remove a

Does this help?  A log can contain all sorts of stuff like linked
libraries for ICA type stuff.  Date/time stamps are normal and can be
used for SBU valuations.  Disk space utilization can be also logged.
Actually, we should have values in a profile that tells us how much
usable space a box needs to be able to install a package.  The same goes
for a dep tree.  If the tree we are building has 6 packages, then we
need to know what the required space usage is before the system starts
building.  Lots of checks and balances are required.

> 3.1.5 Split of Front End and Back End
> alfs will support a seperation of front and back end to complete a 
> client/server architecture. In a client/server architecture the daemon 
> is the process that does all the hard grunt work and the client is just 
> a smaller application that connects to and manipulates a running 
> process. The alfs implementation of the client/server model will be the 
> same, but instead of the daemon running on a remote server, it will run 
> on the target box (e.g. the one that you want a new shiny LFS on). The 
> daemon will run as a service on a box and will have access to statefull 
> information like profile logs, shared object handlers, xml validation 
> and parsing code, etc. It will not provide a gui.

This needs to be updated to reflect the clarification of back-end daemon
and front-end ui that we discussed this week.
> The client will be the gui. It will connect to the daemon (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.)

Well, we all know that GUI will probably be ncurses based at first.  A
command line option is also planned right?  I would also love to see a
GTK or some other such X client GUI as well.  Is it possible that the
client pieces can have a wrapper put around them?  That way the core
pieces are there (in .so's) and then command line, ncurses or gtk
wrappers can be put on the core pieces that stay the same.

> See SplitnALFS for all details on this functional requirement.
> For the implementation of a client/server architecture, we need a 
> clearly defined and supportable communication protocol between both 
> sides. 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.

Looks like SOAP or XML-RPC is in.  I have heard of SOAP before.  I have
never heard of the other.  Which is more mature?  I would go with that
one.  Also, do we need to mention connection options like ssh tunnels
and such?

> 3.2 Usability
> {This section includes all those requirements that affect usability. For 
> example, specify the required training time for a normal user and a 
> power user to become productive at particular operations; specify 
> measurable task times for typical tasks or base the new system’s 
> usability requirements on other systems that the users know and like 
> specify requirement to conform to common usability standards, such as 
> IBM’s CUA standards Microsoft’s GUI standards}

I think we need to get some more in here besides i18n.  Hui had some
good points on that.  I am not sure we can get NLS support in there, but
if we put the mechanisms in for that, then it is just a matter of a
translator putting in the native strings right?

I can't remember of the top of my head, but I do remember a thread
recently that I mentioned something be added here.  Jeremy H - do you
remember?  I think that we need to add requirements that lead us to a
certain conclusion on profile language (XML), daemon language (C?) and
client language (C and/or python?).  The number of external dependencies
should be discussed in here somewhere.  Do we care how many there may
be?  If so, put it in.

> 3.2.1 Internationalization
> The LFS community is made up of many people from many nationalalities 
> and native languages. nALFS should support a facility of i18n plugins. 
> The native language of the tool will be English, but should support the 
> ability of any native language given a person to write a translation.
> 3.3 Reliability
> {Requirements for reliability of the system should be specified here. 
> Some suggestions follow: Availability—specify the percentage of time 
> available ( xx.xx%), hours of use, maintenance access, degraded mode 
> operations, and so on; Mean Time Between Failures (MTBF) — this is 
> usually specified in hours, but it could also be specified in terms of 
> days, months or years; Mean Time To Repair (MTTR)—how long is the system 
> allowed to be out of operation after it has failed?; Accuracy—specifies 
> precision (resolution) and accuracy (by some known standard) that is 
> required in the system’s output; Maximum Bugs or Defect Rate—usually 
> expressed in terms of bugs per thousand lines of code (bugs/KLOC) or 
> bugs per function-point( bugs/function-point); Bugs or Defect 
> Rate—categorized in terms of minor, significant, and critical bugs: the 
> requirement(s) must define what is meant by a "critical" bug; for 
> example, complete loss of data or a complete inability to use certain 
> parts of the system’s functionality.}
> 3.3.1 {reliability requirement one}
>     {The requirement description}

I think we do not need this ATM.
> 3.4 Performance
> {The system’s performance characteristics are outlined in this section. 
> Include specific response times. Where applicable, reference related Use 
> Cases by name. Response time for a transaction (average, maximum); 
> Throughput, for example, transactions per second; Capacity, for example, 
> the number of customers or transactions the system can accommodate; 
> Degradation modes (what is the acceptable mode of operation when the 
> system has been degraded in some manner); Resource utilization, such as 
> memory, disk, communications, and so forth.}
> 3.4.1 {performance requirement one}
>     {The requirement description}

I know we discussed this in the programming language thread.  We need to
lay out what kind of performance requirements we have from both ends.  I
think that the daemon needs to not be hindered in any way by the
language selected, especially on slower boxes.  Remember that it is a
grunt worker, so code execution speed is of the essence.  Think dep
checking and log work.
> 3.5 Supportability
> {This section indicates any requirements that will enhance the 
> supportability or maintainability of the system being built, including 
> coding standards, naming conventions, class libraries, maintenance 
> access, and maintenance utilities}
> 3.5.1 {supportability requirement one}
>     {The requirement description}

We need this section.  We need to put stuff in here that will help to
modularize the tool.  Especially if we want to handle NLS down the road,
that is a supportability issue.
> 3.6 Design Constraints
> {This section indicates any design constraints on the system being 
> built. Design constraints represent design decisions that have been 
> mandated and must be adhered to. Examples include software languages, 
> software process requirements, prescribed use of developmental tools, 
> architectural and design constraints, purchased components, class 
> libraries, and so on.}
> 3.6.1 {design constraints requirement one}
>     {The requirement description}

I don't think we have any ATM.  Let me think on this one.
> 3.7 On-line User Documentation and Help System Requirements
> As with any good application, documentation and help facilities will 
> exist for alfs. Current documents are the ALFS DTD Syntax Document, 
> nALFS Users Guide and nALFS Hackers Guide. These will migrate to the new 
> application as will a new ALFS Logging DTD Syntax Document. These four 
> books/guides should suffice for any help a user may need.
> 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.

Matt makes a good point here.  Nuke all ref's to nALFS and put in his
stuff.  We will document as we go.

(I am going to finish the docs on the old tool first. I still think it
is important.)

> 3.9 Interfaces
> {This section defines the interfaces that must be supported by the 
> application. It should contain adequate specificity, protocols, ports 
> and logical addresses, and the like, so that the software can be 
> developed and verified against the interface requirements.}
> 3.9.1 User Interfaces
>     {Describe the user interfaces that are to be implemented by the 
> software.}
> 3.9.2 Hardware Interfaces
>     {This section defines any hardware interfaces that are to be 
> supported by the software, including logical structure, physical 
> addresses, expected behavior, and so on.}
> 3.9.3 Software Interfaces
>     {This section describes software interfaces to other components of 
> the software system. These may be purchased components, components 
> reused from another application or components being developed for 
> subsystems outside of the scope of this SRS but with which this software 
> application must interact.}
> 3.9.4 Communications Interfaces
>     {Describe any communications interfaces to other systems or devices 
> such as local area networks, remote serial devices, and so fo rth.}

These sections need to be filled in with the conversation points of this
week.  We talked a lot on how the interfaces are going to be laid out.
The UI needs certain things, the comm needs some things, etc.  This
section should not be ignored.  I think we have what we need from this
weeks conversations.

> 3.10 Licensing Requirements
> nALFS will be licensed under the GPL.
> 3.11 Legal, Copyright and Other Notices
> Since alfs will be licensed under the GPL, there are no notices. All are 
> handled by the GPL.
> 3.12 Applicable Standards
> {This section describes by reference any applicable standard and the 
> specific sections of any such standards which apply to the system being 
> described. For example, this could include legal, quality and regulatory 
> standards, industry standards for usability, interoperability, 
> internationalization, operating system compliance, and so forth.}

OK, I think that is a good start.

James Robertson -- jwrober at linuxfromscratch dot org
Reg. Linux User -- #160424 -- http://counter.li.org
Reg. LFS User   -- #6981   -- http://www.linuxfromscratch.org
LFS Bugzilla Maintainer    -- http://{blfs-}bugs.linuxfromscratch.org

More information about the alfs-discuss mailing list