The Component field holds a path composed of one to three segments defined as:

  • Area
  • Section
  • Sub-Section

The Area and Sub-Section are optional, although if the Sub-Section is defined, then the Area must be defined too, so in other words you can use one of the following combinations:

  • Section
  • Area / Section
  • Area / Section / Sub-Section

The component is the continuation of the path defined in the Distribution field, so a complete path is defined as:

  • Distribution
  • Area (if omitted, use "main")
  • Section
  • [Sub-Section]

In a Debian control file, the Distribution and Section fields are used.

So in effect the wpkg environment, just like the Debian environment, is built by segragating each software project in separate distributions, areas, sections, and sub-sections. However, because we do not want to force our users to follow the categorization proposed by Debian, we decided to make use of a new field named Component to replace the Section field.

Below is our proposed categorization, however, if you are creating your own software environment, then you should define your own scheme. The one proposed here follows concepts found in different Linux distributions.


At this point, wpkg offers only two official distributions for binary packages:

  • stable
  • unstable

The stable version works. The unstable version is the one we are working on. It has newer versions of everything, and it work most of the time.

There is one other distribution name used for source packages and which cannot actually be changed and never appears in the Distribution field:

  • sources

If you are using wpkg for your own software environment, we suggest you use your name or your company name to clearly distinguish that distribution from the default wpkg distribution. For example, Made to Order Software Corp. uses m2osw for its own internal distributions.

Another way to use the distribution in a work environment is to define several different distributions depending on who uses what. For example, in a company with developers, testers, and end users you could have three distributions: development, test, end-user.


The area defines a high level categorization of the software. The number of areas is relatively limited and most software fall in the default area: main.

In most cases, a system starts to work with just the core software. The base software adds basic functionality that is generally expected from any system. The main area are software that people commonly use. The optional group adds things that most people do without.

  • core — bare minimum to get a working system
  • base — sensible set of software that render the environment fully functional
  • main — everything which does not fit in the other areas, this is the default if no area is explicitly defined
  • optional — rarely used or quite specialized software


The section defines a low level categorization of the software.

The list of categories ressembles the list of Debian sections, but includes more modern and certainly broader categorizations. We will certainly modify this list as time passes and more projects appear in usys. For now, there are already more sections than projects that we offer in usys!

  • database — database system, tools, libraries
  • devel — development tools such as VCS, static analyzers, performance analyzers, etc.
  • editor — text and more advanced editors
  • education — a software that was created to educate
  • games — any software which represent a game
  • gui — graphical user interface based tools
  • installer — installation tools such as wpkg, pkg_explorer, and all similar tools that help with package management
  • language — compilers, interpreters
  • library — projects that represent one library
  • media — tools related to audio, images, video, browsers, and other graphic and auditory tools
  • miscellaneous — anything else goes here (i.e. other)
  • science — math, physics, biology, astronomy, etc.
  • server — any kind of server like mail, http, ftp, netbios, except database systems
  • tools — console based tools that cannot be placed in a more specific category


The sub-sections are not yet defined and they do not participate in the placement of the file on a software distribution server, thus, it does not really need to be clearly defined in this documentation (i.e. you are free to choose what is best for your software.)

The idea is to offer yet another categorization of you software. For example, if you are offering a video game, it may be a Shoot Them Up, a Role Playing Game, a Wargame, ... this is defined in the sub-section segment. We want this information for tools that offer you to manage such software in a graphical manner.


The final category is composed of all the layers such as:


The --build command uses the concatenation of the path defined by the --output-repository-dir option and the category without the Sub-Section to save binary packages:


Note that when used with source packages, the Distribution field is ignored and sources is used instead:


The name of a package found in your repository follows the normal Debian naming convention (<package>_<version>_<architecture>.deb for binary packages, and <package>-src_<version>.deb for source packages.)

Note that the --build command automatically creates all the directories.