[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problems with love



Hello Miry,

On Tue, Feb 2, 2010 at 6:40 PM, Miriam Ruiz <miriam@debian.org> wrote:
> I'm not really sure about how to make that transition, maybe adding
> love0.5 and love0.6 to the archive and replacing love by a void
> package depending on them (love0.6 | love0.5), but that might be
> overdoing it. Another possibility is to keep the name love for 0.5 as
> it is now and adding 0.6, but it can be confusing.

This reminds me of what debian-science did with octave a few years
ago. They had one source package which they split into two (since
there were two stable branches coexisting at a time). They
continuously maintained at least two source packages from then on.
Here is how they did it (This is somewhat abridged, and somewhat
historically inaccurate in places, but I want to make it concise and
clear):

1) Originally had a source package named "octave" which built multiple
packages, including the binary package "octave"
2) When version 2.1 was released, they uploaded source package
"octave2.1", which produced all the same named binary packages as the
source package "octave"
3) This allowed the maintainers to ask the FTP masters to remove the
source package "octave" since it was a "source packages which have had
all their binary packages taken over by another source packages
("obsolete source packages") " [1]
4) The new "octave" binary package just had a dependency on the new
binary package "octave2.1"
5) The new "octave2.1" binary package provided "octave"
6) when a later version was released, let's call it "octave2.9", they
uploaded the source package "octave2.9." All the binary packages that
"octave2.9" build had the version number "2.9" in the name, and the
binary package "octave2.9" provided "octave"
7) Follow step 6 for subsequent versions
8) when they stopped supporting a version they had it removed per [1] below
9) when they removed "octave2.1", no package built the binary package
"octave" so it was purely a virtual package provided by the remaining
"octave2.9" "octave3.0" "octave3.2" binaries. This is the current
state of octave (octave3.0 and octave3.2 provide octave).

It's actually simpler than it appears, it's just setting it up right
the first time so that it is "automatic" for future releases. Reading
the octave changelog may help, and talking with their maintainer for
pointers (and probably a better explanation than I gave above!)

[1] http://wiki.debian.org/ftpmaster_Removals

Regards,
Scott


Reply to: