Submission Policies

The repository accepts open source and source-available build2 packages. Its submission policies try to achieve a balance between the quality of packages and ease of submission (if you are familiar with the Debian package repository, you will notice many similarities). It is strongly recommended (but not required) that the packages you submit follow the Canonical Project Structure.

The submitted package is first added to where it is automatically tested in a number of build configurations.

Provided the package successfully builds on at least one major platform/compiler combination, it is moved to the testing section of the repository where it will be tested in a wider range of build configurations as well as by interested users.

After some time and provided the package includes at least one test, it is moved to the stable section where it will be continuously built and tested in an evolving set of build configurations.

If a package in the stable section no longer builds on at least one major platform/compiler combination (for example, because it is no longer maintained), then it is moved to the legacy section where it is no longer tested.

Other key points to keep in mind when submitting a package to

  1. Packages are in the source code form.

    Packages can use any free/open source or source-available license. The only requirement is that they are built from source.

  2. Package names are on a first come first serve basis.

    Name squatting, however, is prohibited. If you submit a package without any useful functionality in order to reserve a name, it will be removed and you will be banned.

  3. Package submissions are public and permanent.

    Specifically, packages in the stable and legacy sections cannot be removed under any circumstances.

    Note also that package submissions include your name and email address which will become a part of the public submission record that cannot be altered.

The recommended way to submit a package is with the bdep-publish(1) command. See the Toolchain Introduction for how it fits into the overall development workflow. Specifically, it is a good idea to make use of the CI Service before submitting.

The changes to the and archive repositories are tracked in the corresponding git repositories: (mirror: and (mirror: For the submission service protocol description see Package Submission.