Upstream debian/

Back in 2009 Robert Collins wrote a blog post on “Why upstreams should do distribution packaging“.

As an upstream developer, and rarely a downstream DM, I’d like to say why I package upstream.  Quite simply eat your own dog food.  These days our projects are almost universally consumed via some kind of packaging system, be it apt-get or yum, or one of a zillion others.

To accomplish this my continuous integration (CI) builds packages.  And subsequently the resulting packages get apt-get upgraded as necessary.  So i’m using my project as I expect others to use it.

Yes, but what about the zillion of other package systems?  They are not my itch to scratch. If a bug reporter will provide access to  build machine, I’ll try to fix it.  Or maybe run up a qemu guest instance to see the problem.  Some things are impossible for qemu, e.g. I’m unaware of any way to have a qemu hp/ux guest.

Another good thing is portability testing. The LP PPAs can build for several different Ubuntu releases.  As the system evolves, and the compilers evolve, code stops working.  Of course I’m developing on most recent everything, so the 3 years ago Ubuntu release isn’t what I’m compiling today. It’s nice to know when portability issues like this happen, and a FTBFS email from the build farm is most welcome.

On the Use of PPAs

Whenever the subject of PPAs comes up on he Debian lists, there is instant bikeshedding. If the Debian project provided PPAs, I would switch immediately from Ubuntu LaunchPad PPAs to Debian PPAs.  Of course, the LaunchPad folks may steal the thunder and just do it themselves.

What ever happened to “rough consensus and running code“?
With a working example to emulate, and a pile of allegedly open source code to borrow, what is so hard for the Debian folks to get PPAs to happen?

You can paint the bike shed after the the Debian PPAs are implemented.  Hell, you can theme the web interface for all I care.  The package repository and the build farm are what matters.

Please, note that I only ever upload code that I think will build from source, in the LP build farm.  Some bike shedders (who obviously haven’t used a LP PPA, ever) suggest all this portability building, this will make developers lazy and they will consistently upload crap.  Well, given that it’s a personal package archive, they hurt no-one else. Packages that fail to build (FTBFS) are cheaper than packages that succeed, in both build time and disk space, so this would be appear to be an overall win.