[evolve] Comments about the Debian packaging

[Julien Cristau]

Hi Faheem,

On Sun, May  4, 2014 at 01:31:13 +0530, Faheem Mitha wrote:

> 
> 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.
> 
Note that the evolve tarballs, as generated by setup.py sdist, do *not*
include the debian directory.  So it won't conflict with an external
packaging effort based on those tarballs.

[snip]
> 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.
> 
I don't think so.  You don't mention any specific problems caused by the
presence of a debian dir in the VCS, just in release tarballs.

> 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']
> 
No, the reason for those files being absent is they're excluded from
MANIFEST.in.  Intentionally.  They're present in version control as
quick PoCs or hacks, but don't make sense to package.  If the tests need
adjusting to not crash when these files are missing, then by all means
file issues on bitbucket to address that!

Cheers,
Julien
-- 
Julien Cristau          <julien.cristau at logilab.fr>
Logilab		        http://www.logilab.fr/
Informatique scientifique & gestion de connaissances