Virtual PPA (exposes subsets of packages as separate APT sources)

The following bug report describes an additional layer of logical grouping for PPAs. While individual PPAs per team/user are a very unprecise way of logical grouping (hard to influence and maintain for certain use case) the following idea is meant to provide a more dynamic, but PPA specific, approach to creating logical groups of packages.

Virtual PPAs (further called vPPA) are virtual restrictions of a PPA's available packages. One could say a vPPA is a PPA inside a PPA, although it is not. One can not uplod to them, nor will they have own keys for signing, they are doing no more than representing a subset of the PPA packages which makes more sense to the average user.

There might be a PPA for update testing used for various applications and underlying stacks. The user might not want to conduct update testing on all components but rather a specific application and it's stack. So, in order to prevent the user from accidently breaking his system by installing a broken update of a component he is not even testing anyway, the PPA's owner would create a vPPA per logical component and instruct the user to access that vPPA rather than the actually PPA.
Still, if someone wants to conduct tests on all components they could do so by adding the PPA itself to their sources.list

Advantages:
 * PPA owner doesn't need to create hundreds of PPAs for every logical component
 * PPA owner doesn't need to copy common depends (updated library) across various PPAs and possibly forget about one anyway but instead just make sure the package is part of the affected vPPA settings
 * The users do not have to add hundreds of PPAs, if they don't want/need to
 * The users are saver as they are exposed to a limited list of packages that could possibly break

Internas:
Ultimately Soyuz would use the same package pool across all vPPAs (i.e. the PPA's pool, but restricted through limited versions of the PACKAGES file).
This can probably be archived by using the existing component system (i.e. allow PPA owners to create components besides the original Ubuntu ones and make those use the limited PACKAGES file, while the main pocket always includes a complete PACKAGES file). Another option would be to let them actually appear as individual PPAs using symlinks, though that is a rather hackish approach.
The vPPA management should be editable on-the-fly and it should be possible to copy a vPPA, including it's content.

Example use case:

= Kubuntu PPA =
Kubuntu got a dedicated Launchpad team to maintain PPAs. This team and it's PPAs are forming a logical group based upon a software stack (i.e. the Qt/KDE stack of libraries and applications).

Currently available PPAs are:
* Kubuntu Backports
* Kubuntu Experimental
* Kubuntu Updates
Obviously enough they are mostly reflecting the official Ubuntu archive's structure. They are representing logical groups of packages belonging together, depending on their quality and reliability.

Kubuntu Experimental contains vPPAs for:
 * Amarok
 * KDE
 * Quassel
Those vPPAs represent logical groups based upon subsets of the overall software stack. Amarok itself is getting more and more depdencies, some of those are shared with KDE, some of those are not. So some of the packages uploaded to Kubuntu Experimental belong to the Amarok vPPA or the KDE vPPA, and some of them belong to both.

Jonny, a Kubuntu user, reads about latest Amarok beta and heads over to kubuntu.org. There he finds an article telling him to add a repo line for Kubuntu Experimental's Amarok vPPA to his sources.list. He does so and updates Amarok without any problem. Two days later the Kubuntu developers upload a new KDE beta release with a lot of file clashes and other experimental packaging issues to Kubuntu Experimental. Jonny stays completely unaffected since the Amarok vPPA doesn't expose him to this KDE update, while those users that add the KDE repo line are less fortunate.

Celeste, also a Kubuntu user, likes living on the bleeding edge and got the repo line for Kubuntu Experimental itself in her sources.list. Thus she always gets the latest and greatest Amarok, KDE and Quassel versions. However one day the Kubuntu developers upload new alpha releases of Amarok and KDE creating multiple file clashes, packaging issues and what not. Celeste needs to spend 3 days resolving all the problems but then continues to live on the bleeding edge with only minor issues.

Harald is Kubuntu developer and finds that the Amarok stable upload, he did 2 days ago to Kubuntu experimental, is already fit for a broader audience and wants to move the packages to the Kubuntu Updates PPA. He decides that it probably make sense to preserve the vPPA, so he copies the vPPA rather than the individual packages. Harald instructs users to use the vPPA if they only want to get Amarok updated, because the Kubuntu Updates PPA also includes an all new KDE version which still has some quirks. He himself uses the PPA, because he needs to conduct testing on all packages anyway.