I think you should look at this question that I asked, and got answered:
PPA & Packaging: Having versions of packages for multiple distros
You'd have to package multiple times to get each version of Ubuntu, however you can upload a package for one version, then copy it over to each other version. For instance, I build packages for Lucid, however the same package is compatible with Maverick and later. As such, using the instructions in the aforementioned link, I copy it over to Maverick and Natty within the PPA, and the system then copies/builds it in the background and then publishes the data to the PPA when its done copying.
You need to conceptually separate Ubuntu from upstream, even when the upstream branch is hosted on Launchpad. The vast majority of packages in Ubuntu have their upstream branch hosted somewhere else completely (i.e. GitHub or SourceForge). An upstream project that is hosted on Launchpad might have a closer relationship with Ubuntu, but it should be treated essentially like any other upstream project.
Ubuntu redistributes upstream software usually only making changes when necessary for integrating with all the other software we ship. In most cases, the best option is to fix bugs upstream. That way the fix reach the most people. This also reduces the burden in Ubuntu by not having to maintain the local modifications.
So ideally, the process looks like your first option. You fix the bug upstream, upstream makes a new release, and Ubuntu updates to that version. As you've noticed, things don't always work that way.
Sometimes the release schedules of Ubuntu and an upstream project might not be aligned. Say you've found and fixed a bug that you'd like to see in the next Ubuntu release, but Ubuntu is releasing in three months and upstream has no idea when its next release will be. In a situation like this, the best approach is to fix the bug upstream but backport it to the release in Ubuntu as an Ubuntu specific patch. This is also the case when making a fix in a stable release of Ubuntu where we will most likely not be able to include a new upstream release.
Sometimes Ubuntu carries changes to upstream. If the bug lies in those changes, the fix should go directly to Ubuntu. This includes issues in things like the packaging.
New features are extremely unlikely to be accepted in Ubuntu unless it has already been accepted upstream. We will often accept patches fixing a specific problem before its been applied upstream for the sake of the larger project, but we normally don't like to deviate from upstream in terms of design or functionality.
I know that I'm basically just saying it depends, but it does!
Best Answer
Yes and no.
There is currently no way to use
dput
to upload a package that builds for multiple Ubuntu releases. However, you can accomplish your goal using one of these two methods:Create a Recipe
If you are building a package from a branch on Launchpad and you have Debian packaging, create a daily build recipe that targets the Ubuntu releases you wish to support. This is described in more detail in the latter half of this answer.
This is really the best solution since it also automates new builds every time you make a change (with a limit on one automatic build per day, although you can manually dispatch additional builds).
Upload Multiple Builds Manually
This is not an ideal solution - but it works. What you need to do to make this work is:
Adjust the version number in the changelog to match this format:
...where
[version]
is the package version and[release]
is an Ubuntu release codename (liketrusty
,saucy
, etc.).Make sure the changelog is set to build the correct release. In other words, for Trusty, the first line of your changelog should look like this:
Upload the package using
dput
and then repeat the two steps above for each release you want to upload packages for. You can see an example of how this works here.