Application specific PPA's

[Harald Sitter]

On Mon, Jun 13, 2011 at 4:38 AM, Oceanwatcher <oceanwatcher at gmail.com> wrote:
> I would like to suggest that Kubuntu adopts an application specific policy
> for some of the applications.
>
> Generally, all applications comes from the main repositories. But there are
> some applications where a lot of people like to keep more up to date. And
> thus comes the ppa's.
>
> But it can easily become a nightmare if too many applications are in the
> same ppa - some users want to have one app, others want to have a different
> app. And if an upgrade comes at the same time as another "mass upgrade" it
> can easily sneak in unnoticed. So you have to enable and disable to ppa's to
> stay in control.
>
> Enter the Firefox ppa's. You have one for stable, one for beta etc. So the
> only thing I need to do to stay up to date with Firefox is to enable the
> stable ppa. That means I will get Firefox whenever there is a new stable.
> Not Thunderbird and not Filezilla. So I can leave this ppa enabled all the
> time.
>
> I wish this was the case with some applications in Kubuntu. Amarok, the new
> PIM are two prime candidates. I would actually also like to see KDE SC as a
> separate ppa. This mostaly eliminates the need for the backports ppa, but it
> makes it very clear what comes from what ppa, and you can choose to keep the
> ppa's that you want enabled all the time.>

I do not think this is a viable thing to do for a couple of reasons.

First of all we have much more applications than Mozilla. While they
only produce Firefox essentially (and Thunderbrid/Seamonkey on a
secondary level), we produce a whole software compilation (which BTW
contains KDEPIM) and individual apps such as Amarok and Rekonq and
KTorrent and Quassel etc.

Secondly each of those parts exposes profound dependencies on specific
versions of other components. Like we could not do KDEPIM in one PPA
alone, as it usually depends on the same major version of kdepimlibs,
which in turn depends on the same version of kdelibs. Equally with
most other applications that are not bound to the SC release schedule,
they can change dependencies as they please at any given point in
time.

As a third I believe it to be noteworthy that a vast amount of PPAs
causes a supreme management nightmare. This is partially related to
the first reason with KDE producing vastly more applications than
Mozilla. If we only selected Amarok, KDEPIM and Rekonq to be separate,
that would cause 3*2 equals 6 new PPAs. Each of those PPAs needs to be
quality assured after each upload. Builds for those PPAs ought to be
test built locally with only those PPAs. Uploads of packages to those
PPAs must be done to the right one as otherwise it would defeat the
purpose..... Unreasonable amount of PPAs are certainly not a good
thing.

And for what?

> some users want to have one app, others want to have a different
> app

Now, personally I do not see the argument here. If you choose to use
the updates PPA, then you'd want as many updates as possible,
especially if it helps to keep your system in a consistent state
(inter-component dependencies as mentioned above can break stuff
rather quickly). For the sake of argument, let us assume that one
wants only one application despite the danger of breaking ones system.
How can you make that happen with the regular Ubuntu updates
repository. Well. You cannot. That is, not via the repository.

There are plenty of technical reasons why repository separation is a
dangerous and cumbersome thing to do, some of which I mentioned
already.

That is not to say that your presented use case is completely invalid.
Because it is not. However addressing it with more and more and more
PPAs is trying to tackle the issue from the wrong end. Instead of
separating things on the archive end, it should be a setting on APT.
The reason for this is simple. The archive is always in a consistent
state and as such its quality is as much assured as possible. Each
package within the archive was built against the dependencies that are
to be found in the archive (thus preventing version mismatch issues).
Combined with the assumption that every packager manages dependency
versions appropriately, you could easily tell APT to only install
Amarok, but consequently APT will try to meet the requirements. If
meeting those without breaking parts of the system is not possible
than perhaps you do not want to upgrade Amarok at all, or decide to
upgrade whatever is necessary to be upgraded (which in case of a SC
dep will almost certainly be half the SC).

Long story short. You can easily achieve the same result without
multiple PPAs by using APT pinning [1]. Simply set your preference to
Origin: Ubuntu for everything, and APT will only override an official
archive version with a PPA when you explicitly request this. To that
extent you can of course also do more precise management by excepting
certain packages from this policy etc. etc.

I hope this solves the presented use case.

[1] http://jaqque.sbih.org/kplug/apt-pinning.html

regards,
Harald