Tools/workflow for maintaining packages for multiple distros

Asked by Jason Heeris

Sorry, but this is a bit wishy-washy; I'm writing this in a somewhat desperate state of mind. I work on a project, RabbitVCS, both writing the actual software and doing the packaging for the Debian-related distros. It's the latter that is driving me insane.

Currently, there are about five Debian-like distros in normal usage, Ubuntu Intrepid to Lucid plus Debian. For Debian I'm considering only unstable, since if my packaging targets unstable then testing will catch up soon enough (in our case, there's never been a lag). Also consider that our software is split out into six components.

Say I want packages for Ubuntu in the Launchpad PPA plus a set to download for Debian. Now, say component A differs from Jaunty to Karmic, and it's the only component with this difference that does. I need to make separate packages for Jaunty and Karmic for ALL components now, otherwise the PPA won't work. Up until recently, Python in Debian was waaaay out of sync with Ubuntu, so there's another difference. Eighteen separate "debian dirs" to track this so far. Also, users of the Launchpad PPA since Karmic do not usually type in an apt source line but simply use the "ppa:rabbitvcs/ppa" syntax, which automatically inserts their current series. So even if Karmic and Lucid packaging are **completely identical**, I still need to change ONE WORD in the changelog and re-upload it.

That means 24 different "debian dirs", but the annoying thing is there might only be two or three actual differences across one or two components.

The risks are:

1. My sanity. Every release I have to juggle more than 20 different debianised source trees, ultra-carefully because the PPA is quite unforgiving of mistakes, and there's no sane way to maintain it all. Change one thing, build... if it doesn't work, I have to make a change in a dozen other debian dirs. Repeat. Several are the same, but I still need to separate out the series.

2. Quality. The more packages there are the more likely they are to get out of sync (and in many different ways), and that means problems for myself and our users.

I know there are people out there who maintain single source packages that split out into dozens of debs, and they do it just fine. But seriously, aren't there better tools for this? (Aren't there tools at all for this?) There's so much repeated information, and so much automatic processing of this, that it seems absurd that I have to tweak and prod and poke and maintain it all. But I don't know how to do it better.

Is there a solution?

Question information

Language:
English Edit question
Status:
Expired
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Michael Nelson (michael.nelson) said :
#1

Hi Jason,

Not quite, but it's being worked on. James Westby just put forward a proposal to support multiple distroseries:

https://dev.launchpad.net/BuildBranchToArchive/MultipleSeriesBuilds

as part of the buildbranch to archive work. It'd be great if you could go through the wiki page and make sure all your use-cases are covered.

Revision history for this message
Launchpad Janitor (janitor) said :
#2

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Revision history for this message
Jason Heeris (detly) said :
#3

Sorry for the delay :)

Yes, this wiki (any of the mentioned solutions) would be a great boon to my package management. The sources are identical across all series, except for the version suffix and series line in the changelog (hence my infuriation).

Only comments are:

1. "~karmic" is better than "~09.10.1" ... the latter will make the version look like an unintelligible jumble of numbers (compare full version strings: 0.13.2-1~karmic1 vs. 0.13.1-1~09.10.1 ... even "~k1" instead, since the sorting is the same)

2. Let devs put in multiple series in the series field of the changelog (IIRC that the Debian Policy Manual actually says this is allowed to be supported but isn't really widely used)

It's a great idea!