Implement multi-release support for packages

Bug #235064 reported by Pau Garcia Quiles on 2008-05-26
84
This bug affects 14 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Low
Unassigned

Bug Description

The Debian Policy Manual states a debian/changelog package may specify several releases (for instance, Gutsy, Hard and Intrepid) and the package will be built for everyone of those releases:

     package (version) distribution(s); urgency=urgency
          [optional blank line(s), stripped]
       * change details
         more change details
          [blank line(s), included in output of dpkg-parsechangelog]
       * even more change details
          [optional blank line(s), stripped]
      -- maintainer name <email address>[two spaces] date

http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Distribution

Currently only one distribution is supporting and building for several distributions requires either using the "copy packages" feature (which does not work properly) or uploading the source package once for each distribution. See this thread ( http://thread.gmane.org/gmane.comp.cms.launchpad.user/3647 ) for more information on why "copy packages" fails and this mail ( http://article.gmane.org/gmane.comp.cms.launchpad.user/3654 ) for a couple of cases where this feature would be useful.

Mario Limonciello (superm1) wrote :

PPAs are the best use case for this. The developers for the mythbuntu testing PPA have been doing multiple uploads for newer versions of packaging that go into development releases.

Celso Providelo (cprov) wrote :

Right, Mario, that's understood. But this feature gets severally blocked on the fact that the same source cannot be built more than once in pool-based repositories.

We have to design something that would create Build request with a proper version suffix that would differentiate the binaries produced in the specified distributions.

Colin Watson (cjwatson) wrote :

IIRC the Debian implementation of this (if I'm remembering correctly that this is even supported at all in Debian) works by building it for the oldest listed distribution and then automatically copying the binaries to the others once they're built. That saves having to mess about with different binary versions.

This would only work for sources that build binaries that will actually work on all the distributions at once; however, in many of the situations where one might want to use this, that would be the case. I think that could be an acceptable restriction. Pau, Mario, what do you think?

Alternatively, one could look at the builds for the later distributions as a kind of binary-only rebuild, as discussed elsewhere. I believe the Debian convention for those is to append +b1 +b2 etc. to the binary versions.

I think binary only rebuilds would be a fine solution. There are
enough cases that using the same binaries on later releases wouldn't
work (think package transitions that have alternatives listed in
debian/control)

On 01/09/2009, Colin Watson <email address hidden> wrote:
> IIRC the Debian implementation of this (if I'm remembering correctly
> that this is even supported at all in Debian) works by building it for
> the oldest listed distribution and then automatically copying the
> binaries to the others once they're built. That saves having to mess
> about with different binary versions.
>
> This would only work for sources that build binaries that will actually
> work on all the distributions at once; however, in many of the
> situations where one might want to use this, that would be the case. I
> think that could be an acceptable restriction. Pau, Mario, what do you
> think?
>
> Alternatively, one could look at the builds for the later distributions
> as a kind of binary-only rebuild, as discussed elsewhere. I believe the
> Debian convention for those is to append +b1 +b2 etc. to the binary
> versions.
>
> --
> Implement multi-release support for packages
> https://bugs.launchpad.net/bugs/235064
> You received this bug notification because you are a member of
> Mythbuntu, which is a direct subscriber.
>

--
Sent from my mobile device

Mario Limonciello
<email address hidden>

Celso Providelo (cprov) wrote :

Note that Adam has posted some reasonable arguments against automatic binary rebuilds (+bN) in https://bugs.edge.launchpad.net/soyuz/+bug/245594/comments/5

This feature request is very related to bug #245594 and any decision we make should satisfy both scenarios.

(Note that they are not necessarily dupes, in the case you feel tempted ...)

Celso Providelo (cprov) on 2009-01-14
Changed in soyuz:
milestone: none → pending
Dustin Kirkland  (kirkland) wrote :

I'm marking this bug 'Confirmed', per a current discussion on ubuntu-devel. This would be very useful for PPA's, seems possible within Debian policy, and reasonable to do by building a package for some oldest release and simply copying the binary.

:-Dustin

Changed in soyuz:
status: New → Confirmed
Julian Edwards (julian-edwards) wrote :

We're actively discussing this one (and in fact just tried to estimate how much work it is). I'll post back here after we've made some decisions.

Celso Providelo (cprov) on 2009-05-10
Changed in soyuz:
assignee: nobody → Celso Providelo (cprov)
importance: Undecided → High
status: Confirmed → Triaged
Curtis Hovey (sinzui) on 2010-06-01
Changed in soyuz:
assignee: Celso Providelo (cprov) → nobody
tags: added: feature
Robert Collins (lifeless) wrote :

FWIW an automated copy-forward is probably the lowest hanging fruit, could be tied into the completion of a build. That said, this bug isn't in our current roadmaps - we'd love patches to implement it though!

Changed in launchpad:
importance: High → Low
William Grant (wgrant) on 2012-10-15
tags: added: package-copies
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers