The OSHS Software Factoring and Integration Language is a language that is used to describe a software package for the system. It describes what is in the software package, how to factor usable pieces from it (process known as package building is only a part of software factoring) and how to integrate (again, process known as package installation is only a part of the integration process) the package with the rest of the software in the computer.
To search for what is OSIL like we need to look into RPM. The RPM uses a specially formatted file called spec file written in a special language to guide the build and installation of the package. Similarly, the OPM (OSHS Package Manager) will use a spec file to guide the installation of the package. And the content of this spec file used by the OSHS Package Manager is written in OSFIL.
The problem of software factoring can be described in one sentence as: Given a piece of software and a set of features the user wishes having in the software we need to generate directly usable components of that software that will support all the features the user wishes and will not support features the user doesn't want or need.
The most common form of "directly usable components" are the binaries, files filled with incomprehensible machine code and other, equally incomprehensible, informations for the system loader that describes how to get that machine code into memory and then pass the control to it.
A major component of the software factoring process is package building. This term names the process which takes the source code of the software and generates the binaries and other generated data. A build system is used to automate this process so the process can run unattended.
However the software factoring has another important aspect. Free software packages have optional features, a concept not widely known among proprietary software users. The package builder (often the same person as the user but not always) decides which optional features to support and which not. He then performs what is called build configuration to tell the build system what optional features to build into the software and what to leave out. In sofware packages using autoconf this process may be as simple as entering one (though sometimes very long) command. In other packages it may involve editing one or more files before compilation.
The package manager of the Gentoo Linux Project tries to push the automation of the build configuration process forward. It exploits the fact that in a set of packages there are many features that are supported by multiple packages. The package manager allows the user to express his wishes about the optional features via what they call USE flags and the package manager handles the rest.
Software integration is the process that takes the "directly usable software components" (in vast majority the program binaries) and makes them available to the rest of the system and easily reachable for the user(s) of the system.
As with software factoring, even here is a major component called software installation. The software installation ensures that the software will work in the system. A system-wide software installation makes sure the software will work for any user of the system and a user-wide software installation makes the software work for only one user or sometimes a group of users. In most operating systems a system-wide software installation needs special system privileges while user-wide software installation needs no such things.
However there is more on the software integration. For example some users use a graphical user interface or GUI for short to work with the system. Then the software integration process must sometimes deal with the GUI subsystem when integrating the package, for example adding items to the GUI menu or creating desktop shortcuts. This problem can become really hairy if there are multiple desktop GUI subsystems installed and we want the package being integrated with all of them.
The main reason is that there is no such thing as OSFIL of quality acceptable enough to be considered for reuse in OSHS. The current software integration solutions are either of very poor quality (for example in Windows a too great deal of the software integration work is offloaded to the software installer), inflexible or badly off course due to extremely obsolete designs of some core tools needed for the software integration (for example the RPM system's build process and its spec file must deal with obsolete design of the compiler(s) used and the extremely obsolete UNIX build system called make which ages back to days when computers had 64KiB (yes, KILObytes) of system RAM). And the situation in the field of the software factoring solutions is even worse. The software build system designs, especially of those for UNIX are burdened with legacy of the ancient computers and the programming languages and their compilers are plagued with hacks and kludges patched into them (to cope with larger multifile projects) and incompatible with each other. For the C programming language the autoconf program tries to shield the software users with these hacks and kludges (and it does very good job with that - my own experience) but is unable to shield the developers from them completely, because that is fundamentally impossible with its approach.
The major problem with the current solutions for software factoring and integration is that they try to build two independent systems, one for software factoring and another for software integration. But what if a developer wants to make some part of the software integration support optional? For example Midnight Commander has feature dubbed "optional support for X windows", which really is "optional support for integration with X windows". The software factoring subsystem has to communicate somehow to the software integration subsystem which integration options are available and the software integration subsystem has to take this information into the account somehow when doing its job. If these systems are too independent (for example designed and implemented by two groups that never communicated with each other about this issue), the "optional integration support" feature is either impossible to support or kludges must be employed. This problem is even more visible when one or both subsystems are closed source software or proprietary software with an "look at source code but don't change it" option.
Another reason why OSFIL is developed is that lack of a standard way to specify the software factoring and software integration processes poses a hidden threat for freedom (it is hidden, because it is not seen by the seasoned developers).
| - | OSHS solution for the threat |
| - | Overview |
| - | The P Programming Language |