PPA system overview

Author: CelsoProvidelo Contributors: State: Draft

See http://help.launchpad.net/PPA for the step-by-step procedure to activate a PPA.

See https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/ for more information about packaging specific details.

PPA uses the same subsystems used for Ubuntu primary archive, however they are deployed in a separate machine, so they don't share resources with the Ubuntu setup, apart from the central LP database.

PPA Upload System

It's a FTPd server compatible with dput/dupload tool hosted on: ftp://ppa.launchpad.net/

It works on isolated sessions (jail) where the users will can place the uploaded files in different paths according to the target archive/PPA, e.g.:

• . : default target is temporarily set for ubuntu primary archive

• ./<distribution_name>/ : <distribution> primary archive

• ./~<lp_username>/<distribution_name/: PPA for lp_username matching the <distribution>

• ./~<lp_username>/<distribution_name/<suite_name>: same as before but overriding the changes file target suite.

This logic can be encoded in dput/dupload configuration files allowing a well-integrated development environment.

Upload sessions may contain more than one source upload, i.e. multiple valid changes files. The upload-processor will process them individually and generate a acceptance or rejection email notification for each one.

The upload-processor runs every 5 minutes and by the time you receive an email notification a reference to the just-published source should be available in https://launchpad.net/people/+me/+archive page.

PPA system only accepts source-only uploads. The package versions should be unique across the entire PPA distribution and they should optionally match the corresponding Ubuntu versions in order to avoid problems in installation. For instance, 'foobar_1.0' is the current version in Ubuntu and '1.1' is the new upstream version, then the experimental package in PPA should be 'foobar_1.1~ppa1' (the '~*' suffix will allow the system to be upgraded to the official version of the package, 'foobar_1.1', when it's available).

PPA Build System

Published source uploads will be queued for build immediately after the upload is accepted, then dispatched as fast as possible according to the buildfarm capacity.

The build lifecycle can be observed in the corresponding PPA overview page, quick indication in the table rows and links to the specific builds in the expandable area below each row.

PPA build system supports i386, amd64 and lpia architectures, and we currently have 3 dedicated build-machines for each.

Each build-machine is based in a Xen VM which is reset before every job, so we can guarantee it's not tainted by malicious jobs.

Each build happens inside the corresponding Ubuntu chroot (minimal build environment) and can reach build-dependencies from the Ubuntu primary archive (release, updates and security pockets) and the context PPA.

PPA builds do not respect Ubuntu component policies (ogre-model): all source and binaries are overridden to 'main' component but can install build-dependencies from all Ubuntu components.

The resultant binaries are automatically processed when they are built.

The person who uploaded the source is informed of build failures via email.

PPA Publishing System

PPA publishing system uses the same archive topology used in Debian and Ubuntu primary archives:

• ./pool: stores the package files (source and binaries) organized by component and source name

• ./dists: stores the archive indexes (plain & gz) and Release files

Modified PPA archives are re-published every 20 minutes.

Currently PPAs are unsigned archives, which means that anyone installing packages from them will have to cope with the apt warning message.

The usual ETA from a source upload until having its binaries published in the archive is about 20 minutes.

PPAs statistics and searching

Accessing https://launchpad.net/ubuntu/+ppas a user can see:

• Statistics: number of registered PPAs, number of active PPAs (with, at least, one source publication), number of sources and binaries published across all PPAs for Ubuntu;
• Most active: the 5 most active PPAs during the last 7 days. Activity is measured by the number of new source publications (uploads and/or copies);
• Last 5 uploads: the last 5 uploads or copies happened in the Ubuntu PPAs context;
• Supported architectures: a list of all Ubuntu series and architectures currently supported for PPA.

In the same page users can search PPAs. The search considers the following information:

• Owner name;
• Description;
• Series names with published binaries;
• Published source package names;
• Published binary package names and summaries.

The search results are sorted by relevance and will also include the number of source and binaries published in the PPAs listed.

The cached information used for the search is updated daily (mornings UTC), so the results might not be entirely accurate if you are searching for just-uploaded packages.

Deleting packages from your PPA

PPA administrator (the owner or team-administrator) are able to delete packages using https://launchpad.net/people/+me/+archive/+delete-packages.

This interface operates using search-selected-execute approach on a domain with all published sources which still having files in the archive, for instance, it will allow users to delete partially superseded packages as they do with published ones.

When performed, a deletion will act upon the selected sources and their currently published binaries. The files will be purged from the archive within 30 minutes.

One important detail about how deletion works in practice is that deleting a version from the archive does not allow the user to re-upload it, even if it has exactly the same content. There is a way to recover deleted sources using the Copy-UI, see below.

Copying packages from other PPAs

Any user with permissions to upload to, at least, one PPA is able to access the 'Copy packages' interface of any PPA, see https://launchpad.net/~ubuntu-mobile/+archive/+copy-packages, for instance.

There, using the same search-select-execute approach, the user will have to:

• Select one or more sources to be copied;
• Select one destination PPA he has access;
• Select one destination series;
• Whether or not to copy the corresponding binaries

That's it! Once the copy is executed the packages copied should be visible in the destination PPA, with a note in the details section indicating where they were uploaded originally, when the next publishing cycle happens (within 20 minutes).

When copying only sources, their corresponding build records in the destination context will be created immediately, allowing them to be built as soon as possible.

Depending on other PPAs

The PPA system provides a simple way to combine one or more other PPAs and use the combination as its build environment. It allows very sophisticated collaboration setup across PPAs.

Remember that a PPA already uses the Ubuntu Primary archive combined with its own packages as its default build environment.

Let's describe an use-case:

• Carlos wants to use a bleeding-edge build environment to develop his source 'canjica', it uses GCC and Python to compile and also embeds some features of the bzrlib.

He could use Ubuntu-toolchain, Python-dev and Bzr-dev PPAs on his local machine, but it wouldn't help him to build canjica source with the tools he uses to develop it.

In other words, to use the same environment to build canjica, Carlos goes to https://edge.launchpad.net/people/+me/+archive/+edit-dependencies and includes the mentioned PPAs as dependencies of his PPA.

Done. From now on all builds of canjica in Carlos' PPA will use the most recent versions of gcc, python-dev and bzrlib available in the selected dependencies. No extra work is required from Carlos to keep his PPA using the most recent packages.

That's all for today, folks !