I never understood PPAs. Ever since /etc/apt/sources.list was split up into /etc/apt/sources.d, we've been able to manage repositories using files. Since we already manage the rest of our system files with packages, why not do the same for repos? Dump a sources.d entry, and possibly a GPG key, into a .deb package and give that to users, rather than instructions on how to enter non-standard URLs into a vendor-specific GUI.
http://chriswarbo.net/git/service-packs.git provides a GUI for creating "service packs": packages containing a repository, generated from a list of packages and their dependencies.
Since in this case your binary package would consist of only a text file, building a full-fledged deb package could be considered overkill.
Besides that, installing your binary package would give a signature verification error, requiring the user to manually install your GPG key. But Launchpad and apt-add-repository handle that automatically.
And that's just for users. Think about the difference between the steps involved for repo authors: they could setup and build a package just to install a text file...or they could go to Launchpad, click a few buttons, and have a PPA ready.
Well, it's been a while since I wrote my proof-of-concept, but I managed to get the steps down to:
1. "Open with gDebi"
2. Install package
3. Install "actual, desired package"
The package list can be refreshed automatically using "postpone" (which was new to Debian at the time, but is pretty widespread now).
Also, the "service pack" idea is even more powerful. The package contains the repo, along with a metapackage depending on the "actual, desired package(s)" for which the repo was generated. The repo is unpacked to disk, added to sources.list.d, then the metapackage is installed.
The original idea was to package the closure of a bunch of packages; eg. we can say "include 'gimp', 'inkscape' and 'blender', but not 'ubuntu-desktop'"; that would generate a repo containing gimp, inkscape, blender and all of their dependencies, except for those implied by the existence of ubuntu-desktop. This repo would be packaged up, along with a metapackage depending on gimp, inkscape, blender and ubuntu-desktop. I also made an option to package up security updates.
A nice consequence is the ability to distribute all of the dependencies of a package, but they'll only be used as fallbacks; if newer versions are available, they'll be used instead.
Of course, updates can free up disk space as the need for fallbacks diminishes.
The suggestion to use `postpone` (by which i assume you mean `postpone --debian` ?) to trigger automatatic updates is very interesting, and led me to look into it further, only to discover it's been removed from Debian in Jessie onwards.
The message in the removal email mentions that dpkg triggers fulfil the same task now, have you ever tried/managed to use dpkg-triggers in the same way? It strikes me as likely being impossible as they're run by dpkg itself, which needs to exit before the update can begin...
At this stage it seems like a solution to do this would need to re-package `postpone` for >= Jessie (which isn't impossible, it just makes for one more thing to support).
> have you ever tried/managed to use dpkg-triggers in the same way? It strikes me as likely being impossible as they're run by dpkg itself, which needs to exit before the update can begin...
No, I've not looked at this problem for ~6 years. APTonCD achieves some of the goals I had, so when that became popular I abandoned my attempts.
In fact, I wrote tools to do this many years ago:
https://gitorious.org/debian-repo-packager creates packages for a bunch of repos, including PPAs
http://chriswarbo.net/git/service-packs.git provides a GUI for creating "service packs": packages containing a repository, generated from a list of packages and their dependencies.