[evolve] Comments about the Debian packaging

[Faheem Mitha]

Hi,

I've been looking at the Debian packaging for the mercurial-evolve
extension.

I recently did some Debian packaging for a Common Lisp implementation 
called CCL (see https://bitbucket.org/faheem/ccl-debian) and have also 
done some packaging for a project of my own (see 
https://bitbucket.org/faheem/corrmodel).

Therefore, I have a little experience. Some comments follow. The point of 
this is - do the evolve devs want patches against their Debian packaging? 
I'd prefer to get at least preliminary approval before I go to the trouble 
of making and sending patches.

evolve contains its Debian packaging in a subdirectory. This is a
little problematic. Conceptually, Debian thinks of its packaging as a
separate entity from upstream. What Debian likes to do is pull the
pristine source as a tarball, and then add its packaging. This doesn't
work well if the source already has its own packaging, as that needs
to be deleted. Even if we take the approach that Debian policy is
irrelevant, since we are not trying to be included in Debian, the
Debian build tools are geared towards conforming with Debian policy.

The way this works as of source format "3.0 (quilt)" is that the Debian
expects an orig.tar.{gz|xz} tarball, which *does not* include Debian
packaging. There is an accompanying *.dsc file, and a *debian.tar.gz file,
which contains the packaging. The latter two can be generated if an
unpacked source including the debian packaging is also there (lets assume
that is what we are building in), but the orig.tar.gz is required to be
there.

One approach used by Debian is, given the Debian packaging, there is a
target defined in `rules` called `get-orig-source`, which is supposed to
get (if necessary, create) an orig.tar.gz tarball for the software in
question.

Then one unpacks this orig.tar.gz, copies in the Debian packaging, and
proceeds with the build.

In any case, if upstream wants to have Debian packaging, the two
approaches that won't cause problems are:

a) have the packaging as a separate branch of the repos, all by itself,
and merge when necessary when you need to package.

b) create a second repos for the debian packaging.

Either of these is probably a reasonable way to proceed. I'd suggest (a),
because it would keep the packaging in the main repository. This is also 
how I have the Debian packaging for the corrmodel project referenced 
above.

So, my question is, would the devs be interested in splitting off the
Debian packaging into a separate branch? I also have a patch for the
get-orig-source target which works - I tested it.

Leaving aside this issue, the way the current Debian packaging works
is to use a make target called deb-prepare. This seems to have some
problems.

It does:

     python setup.py sdist --dist-dir ..

and then subjects this to various manipulations. Normally you just
want a copy of the sources. One problem with the current version is
that it is missing (at least) the following files in the resulting
directory:

hgext/drophack.py hgext/obsolete.py hgext/simple4server.py tests/_exc-util.sh

This causes the tests to crash and burn. These files also don't end up
in the Debian package, obviously. I don't know effect that has.

The reason for the hgext files being absent is that setup.py only has

     py_modules=['hgext.evolve', 'hgext.pushexperiment']

But there is really no reason to do any of this, imo.

I'm not subscribed to mercurial-devel, so please CC me on any
reply. Thanks.

                                                         Regards, Faheem