Debian repositories structure

perfSONAR Debian repositories structure

Here is the details of the different perfSONAR Debian repositories that we host.

Considering our release process and the need to support different Debian distributions and derivatives, we currently have a package repository with the following structure:

• 8 distributions — versions:
  • perfsonar-wheezy-3.5 — 3.5
  • perfsonar-wheezy-4.0 — 4.0
  • perfsonar-wheezy-staging
  • perfsonar-wheezy-snapshot
  • perfsonar-jessie-3.5 — 3.5
  • perfsonar-jessie-4.0 — 4.0
  • perfsonar-jessie-staging
  • perfsonar-jessie-snapshot
• 6 suites:
  • perfsonar-wheezy-stable
  • perfsonar-wheezy-testing
  • perfsonar-wheezy-unstable
  • perfsonar-jessie-stable
  • perfsonar-jessie-testing
  • perfsonar-jessie-unstable

Distributions and versions

We name our distributions with the following schema:

1. perfsonar- as prefix
2. the Debian distribution this perfSONAR distribution can be installed on (ex: wheezy)
3. the perfSONAR release version number (ex: 3.5)

We have one or two different release per year. See our roadmap.

The staging repositories

The staging repositories contains packages that are temporary stored before being released to a numbered distribution (3.4, 3.5, ...). This is where our packaging and distribution work happens. This repository shouldn't be used by regular users.

The snapshot repositories

The snapshot repositories contains packages build nightly, or at developers demand, through our automated build system. These packages are a snapshot of the current development code. This repository is only intended for hosts taking part in the continuous integration tests.

Suites

In Debian repository nomenclature, the suites are aliases to the distributions. We are following the same convention as Debian:

• the -stable suite points to the current stable release, this is what most users will want to use,
• the -testing suite points to the current alpha, beta or release candidate (the upcoming stable release),
• the -unstable suite points to the snapshot builds released every night.

Repositories GPG signing

Our distributions and suites are signed with two distinct keys:

• the perfSONAR Debian Archive Automatic Signing Key (snapshot) is used for the snapshots and staging repositories, those distributions/suites are signed automatically by our continuous integration systems
• the perfSONAR Debian Archive Main Signing Key is used for the testing and stable repository, those distributions/suites are signed manually when we release a package or a whole distribution

You can retrieve those keys from the common GPG key servers or from our repository listing.

Usage and configuration

To use any of the previously listed distribution or suite, please refer to our repository listing.

Repositories and packages workflow

For the purpose of the package building, the repositories are split on 2 different machines: the Jenkins building host and the download server. The packages build by Jenkins are stored only on the Jenkins host repositories and signed by the Automatic Signing Key. The packages are then synced to the download server where they are available for user to install and can be released to the release repositories and then signed with the Main Signing Key.

The Jenkins building server contains the following repos:

• perfsonar-wheezy-snapshot
• perfsonar-wheezy-staging
• perfsonar-jessie-snapshot
• perfsonar-jessie-staging

The download server contains the following repos:

• synced from the Jenkins server:
  • perfsonar-wheezy-snapshot
  • perfsonar-wheezy-staging
  • perfsonar-jessie-snapshot
  • perfsonar-jessie-staging
• assembled on the download server itself:
  • perfsonar-wheezy-3.5
  • perfsonar-jessie-3.5
  • perfsonar-wheezy-4.0
  • perfsonar-jessie-4.0
  • all the suites (-stable, -testing and -unstable, which are just aliases)

Packages flow

A regular perfSONAR Debian package usually follows this road:

• On the Jenkins server:
  • nightly and development builds are published to the -snapshot repos and signed with the automatic key
  • release builds are published to the -staging repos and signed with the automatic key
  • repo contents is automatically pushed to a dedicated space on the download server
• On the download server:
  • -snapshot and -staging repos are copied from the the dedicated space and published
  • after being tested, release packages are copied to the -release repos and signed with the main signing key