1

I'm trying to get rid of the last Python 2.x bits on my Ubuntu 20.04 boxes and it turns out the mercurial package is the culprit.

Having already had some negative experiences with the packaged version of Mercurial in the past, I though I could simply install python3-pip and then do the sudo python3 -m pip install mercurial routine.

The binary ends up in /usr/local/bin/hg instead of /usr/bin/hg, but I guess it's okay for most purposes.

Questions:

  1. should I have to expect any negative side-effects as long as I stay clear of packaged mercurial and friends (i.e. packages directly related to it)?
    • As an extension of this, should I use equivs-build (package equivs) to build myself a dummy that will artificially conflict with mercurial?
  2. can I use dpkg-divert at all to symlink the hg binary into the well-known path (/usr/bin/hg)? Or will this only actually work if my dummy package takes care of it? Since I am using hg via SSH I am afraid that there is a chance the hg binary won't be found (Mercurial works by establishing an SSH tunnel and invoking hg to communicate via std{in,err,out} with the client) ...
0xC0000022L
  • 5,720
  • Did you tried this method? It is 100% python3. – N0rbert Jul 17 '20 at 05:40
  • No, I haven't. But for starters any package installed without making the package source known to apt is a sore spot (subverts my aim to use Ansible for as many aspects of system configuration as possible). And making this package source known to Ubuntu 20.04, while possible (pinning and all), is anything but desirable. Since I am also maintaining a Mercurial extension, I can live with having Mercurial installed "outside of the package manager". But installing a package from Debian experimental and doing it from this source seems a bit too risky for my taste. But thanks for the pointer. – 0xC0000022L Jul 17 '20 at 14:17

0 Answers0