This location is used by debian (and ubuntu) to store completions provided by
other deb packages. The default fpath appears to have this before any of the
zsh-provided instances of the completions, so this should take precedence.
Differential Revision: https://phab.mercurial-scm.org/D882
For builds that run on hermetic environments, it's possible that the "less"
package is not installed by default, yet it's needed for tests to pass after
revision ca1519568a93 (which sets less as the fallback pager).
Now that environment variables override system-wide hgrc settings, we
can default Mercurial to sensible-editor and sensible-pager by default
for debian users.
Per discussion on the mailing list and elsewhere, we've decided that
Python 2.6 is too old to continue supporting. We keep accumulating
hacks/fixes/workarounds for 2.6 and this is taking time away from
more important work.
So with this patch, we officially drop support for Python 2.6 and
require Python 2.7 to run Mercurial.
Debian maintainers already have this and lintian warns us about not
listing 'wish' as a dependency or suggestion so this patch does indeed
just that. The issue, by the way, is that we are shipping hgk (which is
written in tcl/tk) so we should be good citizens and list wish (a meta
package for tcl/tk) as a dependency.
Leaving the hgk binary in /usr/bin causes some lintian warnings, and
downstream packages poke it in /usr/share/mercurial, so we'll just
stash it in there. Rather than patch hgk.py as part of the Mercurial
install, just drop a config file in /etc/mercurial/hgrc.d that points
to the installed hgk.
This is a much larger commit than I'd like, but I honestly don't see a
good way to break it up and leave things working. Summary:
We now use debian/rules with debhelper to build our debs. This is much
more standard, and means we use dh_python2 to do things like handle
leaving .pyc files out of the built debs.
The resulting package is split into mercurial and mercurial-common,
with the former being the hg stub and all the native .sos, and the
latter being basically everything else.
builddeb and dockerdeb are updated to use the new system. The old way
(using dpkg by hand) breaks with the above changes because
debian/control no longer contains a version string (that's now guessed
from the phony changelog.)
Tests are updated to assert that the right files end up in the right
debs.
Future work will allow us to use docker to build debs.
Right now this doesn't install any config files. I plan to do that as
a followup, but getting something basic and working checked in seems
like more of a priority than getting everything done in one big step.
This also does not create a source deb yet. I haven't looked into that
process.
Note that this declares incompatibility with the `mercurial-common`
package. It's typical for debian packages to be split between
architecture-independent bits and native bits, meaning the python bits
downstream live in mercurial-common and the c extension bits live in
mercurial. We don't do that because we want to (ideally) give users a
single deb file to install.
