launchpad helpLaunchpad Help > Packaging > Source package branches
|
|||
Source package recipes in Launchpad
Overview
Launchpad can build Debian-style packages for Ubuntu directly from source code in Bazaar branches hosted on Launchpad or imported from elsewhere.
You can configure Launchpad to perform these builds automatically once a day (if the source has changed) or when you request them through the web interface or Launchpad's API.
Packages built this way are most useful when you enable automatic daily builds and so these guides will concentrate on using them in that way.
How source package branches work |
1. You tell Launchpad where to find the source code you want to build. |
2. You write a recipe that tells Launchpad where to find packaging instructions and how to apply them. |
3. You tell Launchpad when you want the builds to happen |
• each day (if there has been a change in the source) |
• or only when you ask for one (either through the web or API). |
4. Launchpad builds a source package. |
5. Launchpad builds the source package into a binary and puts it in the PPA you specify. |
If all you want is a build test, you can discard the build results. Usually, though, you'll want to keep the resulting packages and make them available for testing.
As the build process is automatic, the resulting packages can be risky and you should take care when using them. You should do what you can to minimise any risks to people who install your automatically built packages.
However, don't be put off. While packages built this way are not for the average user, when you deploy them in the right circumstances, and with due diligence, the benefits can certainly outweigh any risks.
Why use daily builds?
Testing is the main use for packages built this way, particularly if you opt for automatic daily builds.
Here's why:
- Testers can install the latest code almost straight away, tightening the feedback loop between developers and testers.
- It lowers the barrier to entry for new testers: they can add the PPA and install your package, then receive automatic updates, rather than building from source.
- Visibility of bug fixes: people can easily verify that their bug has been fixed in a version of the code not yet officially released.
There could be some downsides to using daily builds, so they may not be suitable for your project.
Possible downsides include:
- If your project doesn't use feature branches or keep trunk in a buildable state, then daily builds might be not be valuable to you.
- If your project is in the early stages or in the middle of a major refactoring and you're not ready for testing then daily builds won't be useful.
- Sometimes users think daily builds are supported releases and this can add to bug noise.
- If users cannot easily go back to their previous version of your software after using daily builds (for example, there is a one-time database upgrade between versions) this may lead to increased support requests.
Setting up a daily build
If you would like to set up a daily build then see BzrBuilder for one way to do this. Be sure to also check out GoodDailyBuilds for some tips on how to ensure that the daily build will be most useful. Running daily builds are not maintenance-free, you need to follow upstream development so that if the upstream project adds or removes dependencies your builds don't break.
Available daily builds
See AvailableDailyBuilds for a list of some of the daily builds available. Builds on this page should adhere to the principles in GoodDailyBuilds.
