launchpad development
Building Multiple Series
It's common for people to build for multiple series in their PPAs (daily or not).
This is because they want to provide backports for older series, not just concentrate on the current series as Ubuntu do. This is one of the main pulls of having a separate archive to play in. It's perfectly acceptable to just build for the current series and leave older series frozen if that is desired, and we won't take away that ability.
Current Situation
This is currently tricky to do. It requires building a source package per-release, with appropriate version numbers, and upload each of them. There are tools such as jkakar's autoppa to automate this.
Often people will start from the same unpacked source for each series, and just tweak the changelog, but sometimes they want to alter things such as build-dependencies for older series. We will not handle this latter use case, if they want different source then they have to produce both.
In addition people typically build the source packages on a single release, as the differences don't materially matter to the created source package. It's theoretically possible that the differences could matter, and each source package should be built on the series they are intended for, but this is rare, and use shows that people will tend to not hit issues or work around them if they do. Therefore we can use either a system that produces source packages on a single release or all releases, with a slight preference for all releases if everything else is the same.
Aim
We wish to provide a system where it is a single action to build something for multiple series. The user won't care much how it is implemented, they would just rather have to avoid creating multiple source packages themselves and uploading each of them.
The input will be a recipe and a list of series to build for.
The system should aim not to proliferate recipes that are user-visible, but should aim to allow them to be shared and built upon for all series that are built for.
Version Numbers
As we said that we would not support building materially different source packages based on the target series we only have to cause differences in the version numbers.
The usual scheme is to append ~karmic1 or ~09.10.1 to the end of version numbers to indicate the series they are intended for.
The main thing to consider is that they sort correctly, older series must be strictly less than all newer series so that the packages get correctly upgraded when the user moves to a new release.
Implementation
There are two options to implement this feature:
Option 1 - rebuild the binaries
As most users are perfectly happy with a single source package building several releases we could make use of that:
- The recipe is used to build a single source package (on development release?)
- This is built in each target series overriding the version number to produce binary packages with the desired version.
This ensures that the binary packages get the correct version number, uses a minimum amount of build time and only uses a single recipe. It does however require some mangling of the contents of the package at the start of each binary build, which isn't too elegant.
I believe that there is some work in soyuz already done towards implementing this, but I don't know how far along it is.
Option 2 - recipe feature
This option uses a recipe with a feature to amend the version number computed from the template.
- The recipe is dispatched once for each target series to a builder of that series, along with the version suffix to use for that series.
- Each builder produces a source package, asking bzr-builder to add the version suffix to the version number as it builds it.
- Each produced source package is uploaded and built as it would if it was the only series.
This option uses more buildd time to produce multiple copies of what will usually be an equivalent source package, still only uses a single recipe, but does not allow users to do the same thing with source packages they have uploaded (or Ubuntu to do rebuilds without uploading a source package.)
Storing Recipes
Which series do you pick for the traversal to a recipe that is used to build for multiple series?
Should recipes store which series they have been successfully used for?
What happens when we open a new development release, there will be zero recipes associated with that series for people to choose from.
Conclusion
Either option would solve the problem, with option 2 being more expensive but avoiding any (unlikely) problems that would occur building a source package on a different series than it is being uploaded to. Option 1 is also more general, allowing us to build other features such as the (long desired) possibility to do no-change rebuilds in Ubuntu without uploading a source package. Option 2 is probably the easier to implement, depending on how far the work on Option 1 has already progressed.
