KarmicAptUrlPpaPolicy

Summary

Its currently difficult to add a PPA. We want to discuss a process to add PPAs easily, preferably using apturl. We need to find a process/policy/automatic-test that ensures that there are some QA standards that will be followed.

Release Note

This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

It is mandatory.

Rationale

There is a need from both developers and users to have software that is not available in the ubuntu archive (e.g. newer versions, not yet packaged versions etc). Launchpad PPAs provide a good way for this. They have the advantage over other third party sites is that the build environment is controlled and that more automatic tests can be performed. Making it too easy OTOH is not ideal because everyone can upload anything to a PPA (including packages of bad quiality or trojaned software).

User stories

Joe runs 8.04 but needs the latest bzr package for his development. The bzr package is available in the bzr PPA and he wants to add it easily.

Design

For 9.10 we will focus on making the tools on the desktop better. Software-properties should be extended to make adding PPAs (including the signing key) available via a single input entry. In addition to that we will include a "enable-ppa" script at the commandline that performs the relevant actions.

9.10 plan:

  • Continue to use white-list for apt-url - while extending as capabilities of LP apis to provide anonymous searches for available PPAs
  • Allow easy enabling of PPAs (including getting the key) via Software sources into a file in /etc/apt/sources.list.d
  • Separate 3rd-party updates in the update manager and how what update comes from where
  • Launchpad to add apt-url for all ubuntu archive packages etc.
  • Launchpad to start working on api for whitelist (but is blocked on non-anon access to api)
  • Launchpad to start working on ppa search via api (but is blocked on non-api access to api)

Implementation

The software properties application is expanded so that when a PPA is added (via ThirdParty/Add) the key is automatically fetched from launchpad. This requires that launchpad exports the keys into a additional resource than just keyserver.ubuntu.com (it will not be able to handle the load).

When the user selects "ThirdParty/Add" a shorthand syntax for adding PPAs is provided "ppa:name" or "ppa:owner/name".

A commandline application call "add-apt-repository" that takes a argument like "ppa:mvo" (or "http://foo.bar/deban packages main".

When launchpad supports a API to get information about dependencies for a PPA (ppa-A depends on ppa-B) this will be added to software-properties as well (currently its only doable via screen scraping).

UpdateManager is modified so that it shows information about what packages come from what PPA. When launchpad provides a way to get the raw debian/changelog file for a given package from a PPA update-manager will include changelog support for PPAs as well (see https://bugs.launchpad.net/soyuz/+bug/118870).

UI Changes

The add dialog help text should be updated to reflect the new "ppa:name" feature.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

Adding PPAs via apturl is only possible if the PPA is part of the ubuntu whitelist and follows the ThirdPartyRepositoryWhitelist proces (https://wiki.ubuntu.com/ThirdPartyRepositoryApplicationProcess). There is a certain desire to add apturl support for adding PPAs that do not follow this process but a different one. When launchpad get support for PPA ratings and automatic QA tests we will discuss this again.

BoF agenda and discussion

  • how to make adding PPAs easier
  • how to ensure that the PPA passes some automatic QA checks
  • what policy do we need to ensure that packages from the PPA do not de-stabelize the

This is rickspencer3: I feel strongly that: 1. It should be much easier than it is for developers to get their apps to users, and it should be much easier for users to install such software. PPAs is potentially good way to do this. Finding PPAs and exchanging keys should be much easier. 2. The way that users get PPAs (or whatever the solution is) should be very seperate (but still easy) from the way that users install software that has run the relevant Ubuntu gauntlets.

As I said I would, I've compiled some mock-ups of what I was talking about at the session: http://doctormo.wordpress.com/2009/06/01/ubuntu-apt-url-and-the-white-list/

This is Clorox: Will it be able to add non-PPA repositories, such as http://deb.opera.com/opera/ and http://download.skype.com/linux/repos/debian? That would make it easier for Ubuntu to "just work", so that a proprietary software manufacturer such as Opera or Skype can just place an apturl on their download page. One clicks on the download link (apturl), the "trust this repository" popup shows up, and automagically, the app is installed.


CategorySpec

FoundationsTeam/Specs/KarmicAptUrlPpaPolicy (last edited 2009-07-13 12:10:31 by p54A654F3)