Mathias Hasselmann

Launchpad's Personal Package Archives

Probably inspired by openSUSE's Build Service Launchpad provides this excellent Personal Package Archive (PPA) service.

It's quite exciting service: You just request your PPA, upload your source packages via dput command, and get them built within freshly setup Ubuntu environments. When building succeeds your packages are placed within some apt-get repository. No further maintenance steps required.

Unfortunately the service is not perfect yet: It seems to be driven by cron jobs and you only get feedback per mail. This makes the entire process very slow and inefficient. You have to find tiny tasks to fill up the 10 to 20 minute delays. Those tasks are rare, so at least I either end up idling/chatting or doing larger tasks. Very distracting. As a result it takes several hours until I know, that some PPA package is ready for use. I absolutely do not like this working style, I prefer staying focused on my current task, instead of wildly jumping arround between tasks.

Well, but this is just a minor annoyance, compared to the fact that PPA doesn't seem to allow you to delete/overwrite the upstream tarballs forming the base of your self-made Ubuntu packages. The idea of immutable upstream tarballs works nicely if you assume, that you aren't the maintainer of the software uploaded to your PPA: In that scenario you take an upstream tarball and apply patches until it works properly in Ubuntu, but you have no serious chance to modify the upstream tarball.

Things are different when you use PPA to publish software you maintain. In that case it happens, that you use PPA to package your release candidate and test it on your various Ubuntu VMs. During tests you spot minor show stoppers, commit fixes to your code repository, and run "make dist" to get another release candidate. After that you increase the PPA release number in debian/changelog and invoke "debuild -S -sa" to get the next interation of your Ubuntu package. Next step would be uploading that fresh package to your PPA, but that fails since suddenly the MD5 hash of your upstream tarball has changed. Of course! The bugfixes! Duh!

Only solution I've found so far: Skip an upstream release to make PPA happy. Not very convincing. Maybe the LazyWeb has some suggestions to work around that limitation?

Update: Yes, I didn't update the tarball's release number. It's just a release candidate. I'd expect a personal package archive to support release candidates. I prefer PPA over "debuild -i", since the build services attached to PPA provide a clean build environment.

Comments

Laney commented on March 7, 2008 at 9:41 p.m.

From the Launchpad news feed (http://news.launchpad.net/releases/la... ):

"Faster PPA builds: we’ve cut the time it takes to build packages in PPAs. The moment you upload your source, Launchpad starts building."

Good times?

Mathias Hasselmann commented on March 7, 2008 at 10:53 p.m.

@Laney: Oh, I just thought to be lucky, when the build farm picked up my archives quickly last few times. Good times, indeed!

Michael Trausch commented on March 8, 2008 at 4:48 a.m.

I tend to use pbuilder (and some homebrew scripts) to test builds before I upload them to PPA. I upload them to PPA when I want to exhibit them for some reason... I build them on my own machine to make sure they build properly, because the turnaround is *much* faster.

Ross Burton commented on March 8, 2008 at 11:02 a.m.

It really sounds like you want pbuilder. I suggest you use cowbuilder too, because that makes creating the pristine environment a lot faster.

My workflow for the OpenedHand package archive is to produce a clean Debian Sid package with svn-buildpackage/pbuilder, and then run a small script which adds a changelog entry and rebuilds it (again using pbuilder) for etch, feisty and gutsy.

Christian Reis commented on March 8, 2008 at 11:46 a.m.

We're working on two improvements to the PPA workflow that make the lags a bit less frustrating: first, we now dispatch builds as soon as your package is accepted; second, you will be able to see the ETA for your builds and the order in which the build farm is processing.

One additional improvement, which is to allow authenticated uploads via SCP/SFTP to be synchronously verified, would give you immediate feedback on problems. That's scheduled to be worked on after July.

As for relaxing the orig-overwrite constraint, the issue is slightly tricky to handle correctly. We've added help text to the PPA package deletion page that attempts to clarify that. You can see it by expanding the help tab at https://launchpad.net/people/+me/+arc...

Thanks! Do check our bugtracker for inconveniences, and report ones that aren't filed: https://bugs.launchpad.net/soyuz/

Loïc Minier commented on March 9, 2008 at 10:12 a.m.

Concerning upstream tarballs, you should simply version your package appropriately: if you upload a RC version of a coming release, name it 1.2.3-rc1, if you upload a SVN snapshot you could name it 1.2.3~svn20080309 etc.

If you follow this scheme, you'll effectively upload a tarball each time and will not have file conflicts issue; also people on the internet wont be confused if the real 1.2.3 tarball differs from the RC 1.2.3 tarball you've uploaded as yours will be named differently.

Mathias Hasselmann commented on March 19, 2008 at 4:22 p.m.

Loïc: Yes, injecting additional, artificial version strings is possible, but requires editing of configure.ac, additional commits and whatever... Far too much effort for __personal__ pre-release testing.

Guess I really should invest the time needed for learning usage of pbuilder.

Loïc Minier commented on April 20, 2008 at 5:27 p.m.

You don't need to patch configure.ac; you can really just change the Debian version and rename the tarball. What matters is that people upgrade automatically to what compares to be a higher version.