Chapter 27. Managing the Package Repository
Table of Contents
A source distribution of eCos consists of a number of packages, such as the kernel, the C library, and the µITRON subsystems. These are individually versioned in the tree structure of the source code to support distribution on a per-package basis and to support third party packages whose versioning systems might be different. A command-line tool, ecosadmin.tcl is used is used to manage the installation and removal of packages from a variety of sources with potentially multiple versions. The eCos Configuration Tool provides a graphical user interface to this tool through a dialog box as illustrated in Figure 27.1, “ Package Administration ”.
27.1. Package Installation
ecosadmin.tcl, the eCos
Tool, is a command line tool that allows administration
of packages within an eCos Repository. This tool is a Tcl script
which allows the user to add new eCos packages and new versions of
existing packages to an eCos repository. Such packages are
distributed as a single file in the eCos package distribution
format and, by convention, eCos package distribution files are
Unwanted packages or versions of packages may also be removed from an
eCos repository using this tool, and a GUI interface to this tool
provided by the eCos Configuration
27.1.1. Using the Package Administration Tool
The graphical interface accesses all the functionality of the command-line tool and may be accessed from the menu option Figure 27.1, “ Package Administration ” is displayed.→ . You will first be prompted to save your existing configuration before the dialog in
Figure 27.1. Package Administration
The dialog displays the packages which are currently installed in the form of a tree. The installed versions of each package may be examined by expanding the tree.
Packages within a package distribution file (traditionally with a
.epk suffix) may be added to
the eCos repository or, if using multiple repositories, the
top-most repository by clicking on the
Add button. You will be prompted to provide
the location of of the
package distribution file via a File Open
Packages may be removed by selecting a package in the tree and then clicking on the Remove button. If a package node is selected, all versions of the selected package will be removed. If a package version node is selected, only the selected version of the package will be removed.
27.1.2. Using the command line
The ecosadmin.tcl script is
located in the base of the eCos repository in the
packages sub-directory. The command
operates by default on the eCos repository pointed to by the
ECOS_REPOSITORY. Use a command
of the following form:
$ tclsh ecosadmin.tcl <command>
The following commands are available:
- add FILE
Adds the packages contained with the specified package distribution file
FILEto the eCos repository and updates the package database accordingly. This command also takes the option
--accept_licensewhich accepts the licensing terms of the packages being installed without displaying them and prompting for their acceptance, as well as
--extract_licensewhich extracts only license file of the packages into the repository as
On windows hosts, this comman includes the option
--noconvert_textto suppress conversion of text files to windows format (crlf) to retain text files in their original (unix) format. The default is all text files will be converted to native windows format (crlf).
- remove PACKAGE [ --version=VERSION ]
Removes the specified package
PACKAGEfrom the eCos repository, as well as all targets which use that package, and updates the package database accordingly. Where the optional version qualifier is used, only the specified version
VERSIONof the package is removed. This command also takes the options
--keep_docs, which preserves the documentation of removed packages, and
--keep_targetswhich retains targets which use the removed package.
Produces a list of the packages which are currently installed and their versions. The available templates and hardware targets are also listed.
Merges all the packages within the package directory
ECOS_REPOSITORYinto the current repository (defined by the environment variable
Check the package database, listing targets that refer to non-hardware packages or non-existent packages, as well as orphaned hardware packages (packages not used by any target).
Remove a target definition from the eCos database file.
Filter out missing packages from the eCos database file.
It is possible to remove critical packages such as the common HAL package using this tool. Users should take care to avoid such errors since core eCos packages may only be re-installed in the context of a complete re-installation of eCos.
All commands above take the option
provide the path to the repository that is to be operated on. The
default is the value of the
ECOS_REPOSITORY environment variable.
27.2. Package Structure
The files in an installed eCos source tree are organized in a natural tree structure, grouping together files which work together into Packages. For example, the kernel files are all together in:
and µITRON compatibility layer files are in:
The feature of these names which is of interest here is the
<version> near the end. It may seem odd to
place a version number deep in the path, rather than having something
The rationale for this organization is historic as in practice
developers maintain their source code under revision control systems
such as Mercurial, GIT or SourceSafe using the version directory
current in place of
is favored by most developers.
schema is still maintained as it does permit developers to easily switch
between different versions of specific packages within their
configuration without having to manipulate their revision control system
or partion packages into their own revision control system. It also
permits develops to upgrade only specific packages to newer versions
while retaining the remainder on earlier versions that have been
previously qualified by a standards or certification agency.
27.2.1. Integration with Revision Control Systems
Many developers have their own source code control system, version control system or equivalent, and will want to use it with eCos and eCosPro sources. Since new releases of eCos and eCosPro come with different pathnames for all the source files, a little work is necessary to import a new release into your source repository.
For example, eCosCentric maintains
Mercurial, a distributed source revision
control system, using a number of source repositories with all package
eCosPro release is constructed by merging all
repositories into a new single release directory and renaming all
current directories to
, as well as
<version> of all templates.
An eCosPro release may therefore be
returned into a source revision control system by renaming all
packages back to
current and committing
the resulting directory structure into the repository.
“current” is recommended because ecosconfig recognizes it and places it first in any list of versions.
For example, within a POSIX shell environment such as bash (normally available under Linux and provided with the eCosPro host tools for Windows hosts) use the following command:
find . -name
<version>-type d -printf 'mv %p %h/current\n' | bash
Having carried out such a renaming operation, your source tree will now look like this:
which is a suitable format for import into your own source code control system. When you get a subsequent release of eCosPro, do the same thing and use your own source code control system to manage the new source base, by importing the new version from
and so on.
The eCos build tool will now offer only the “current” version of each package; select this for the packages you wish to use.
Alternatively you may choose to create two versions of each package
current containing the
<version>. For example:
$ECOS_REPOSITORYfind . -name
<version>-type d -printf 'cp -r %p %h/current\n' | bash
Having carried out such a copy operation, your source tree will now look like this:
In simple terms, while you initially may have two identical version
directories, when you overlay a new version on top of an existing
directory tree, the older files within
current will be replaced by the newer
. Within your
configuration, however, all packages marked to use the older
version will remain fixed while those marked to use
current will switch to a newer version.
The above method of overlaying directories however is strongly
discouraged. For example, the file
ecos.db is not versioned and is common
to both releases'
directories so only the last version of the file will be retained
with the contents of previous versions lost. In addition, common
target definitions within
ecos.db may differ between releases.
To work around these issues, developers are strongly advised to use
the merge command of the
ecosadmin.tcl tool which will
merge the two versions of
ecos.db in addition to overlaying new
the target repository. In addition, while merge will copy over the newer
subdirectories it will not
replace the contents of pre-existing subdirectories such as
current. This may, however, be
made an option in a newer release of the ecosadmin.tcl tool and currently can be
overcome through the following commands:
NEW_REPOSITORYfind . -name
<version>-type d -printf 'cp -rf %p/.
$ECOS_REPOSITORY/%h/current\n' | bash
For the example given, the updated target definition
in the merged repository will require use of the new device driver
not present in the older release as a result of the updated target
Making such a change has implications for any build trees you already have in use. A configured build tree contains information about the selected packages and their selected versions. Changing the name of the “versioning” folder in the source tree invalidates this information, and in consequence it also invalidates any local configuration options you have set up in this build tree. So if you want to change the version information in the source tree, do it first, before investing any serious time in configuring and building your system. When you create a new build tree to deal with the new source layout, it will contain default settings for all the configuration options, just like the old build tree did before you configured it. You will need to redo that configuration work in the new tree.
Moving source code around also invalidates debugging information in any programs or libraries built from the old tree; these will need to be rebuilt.
|2023-01-12||Open Publication License|