[Pkg-octave-devel] Concurrent maintenance of the Octave packaging

[Jordi Gutiérrez Hermoso]

2011/10/5 Sébastien Villemot <sebastien.villemot at ens.fr>:
> Jordi Gutiérrez Hermoso <jordigh at octave.org> writes:
>
>> I know that the usual Debian practice is to strip the debian/
>> directory if a source tarball contains it, but that's usually because
>> there isn't very good communication between Debian and upstream. Now
>> that we're actually moving towards keeping the tarball source with the
>> Debian packaging, perhaps this can be an overall good move? This
>> should ease the burden of packaging if it's shared between Octave and
>> Debian developers.
>
> Assuming that this workflow is desirable in terms of task sharing
> between developers (which is not obvious to me), I don't see how we can
> implement this in an elegant way.
>
> For example, suppose that we have created the official Debian package
> using the debian/ dir of the upstream tarball as you suggest, and that
> later we need to change the packaging before a new upstream release
> happens (there are many reasons why we may need to do so), then:
>
> - either our package is of the "3.0 (native)" kind, and we need to
>  create an artificial upstream number and an artificial upstream
>  tarball containing the required changes;
>
> - or our package is of the "3.0 (quilt)" and then dpkg-source erases
> the debian/ dir of the upstream tarball when uncompressing the
> source. So we have to provide another (possibly modified) version of
> upstream debian/ dir in the debian.tar.gz.

How about having two separate packaging branches in hg? Say,
packaging-stable and packaging-default. The merges should happen
regularly in order to make the following inclusion lattice diagram
usually true:

    packaging-default
     /           \
    /             \
default         packaging-stable
    \             /
     \           /
        stable

I.e. regularly merge stable onto default and onto packaging-stable
*and* regularly merge both default and packaging-stable onto
packaging-default. Merges are fairly cheap if they're done frequently
and incrementally, so I don't think this is an excessive amount of
extra work.

The packaging branches should contain the debian/ and whatever .spec
stuff seems useful (and similar packaging information for Windows and
Mac OS X?). The official Debian packaging can simply mirror the
packaging-stable branch in Savannah and we can regularly push on that
branch whatever changes the various distribution packagers deem
necessary.

On the Octave side, we can regularly maintain the packaging-default
branch so that the packaging is "always ready", so that when a new
major Octave release happens, we can use what has been collaboratively
maintained there as the basis of a new Debian packaging. We can also
keep more than one .spec for Fedora, for SuSE, and whatever else, but
we don't need to distribute them in tarballs.

Is this simple enough? Or too complicated?

- Jordi G. H.