[PATCH 3 of 6] packaging: upgrade Debian packaging to build with Python 3

Yuya Nishihara yuya at tcha.org
Mon Oct 21 22:28:59 EDT 2019


On Mon, 21 Oct 2019 19:13:48 -0700, Gregory Szorc wrote:
> On Mon, Oct 21, 2019 at 6:26 PM Yuya Nishihara <yuya at tcha.org> wrote:
> 
> > On Mon, 21 Oct 2019 09:59:10 -0700, Martin von Zweigbergk wrote:
> > > On Mon, Oct 21, 2019 at 9:53 AM Yuya Nishihara <yuya at tcha.org> wrote:
> > > > On Mon, 21 Oct 2019 09:01:51 -0700, Gregory Szorc wrote:
> > > > > On Mon, Oct 21, 2019 at 6:57 AM Yuya Nishihara <yuya at tcha.org>
> > wrote:
> > > > > > On Mon, 21 Oct 2019 12:00:55 +0200, Denis Laxalde wrote:
> > > > > > > # HG changeset patch
> > > > > > > # User Denis Laxalde <denis at laxalde.org>
> > > > > > > # Date 1571648394 -7200
> > > > > > > #      Mon Oct 21 10:59:54 2019 +0200
> > > > > > > # Node ID 09f95d7a20c6d2e0bf6218e2a5bc9cd2b803c8ec
> > > > > > > # Parent  70764c9ddba397fa6cc2c92a28a1a65c5bdddaea
> > > > > > > packaging: upgrade Debian packaging to build with Python 3
> > > > > > >
> > > > > > > Also drop the explicit "Depends: python" as debhelper will add
> > it.
> > > > > >
> > > > > > So, are we ready to ship py3 version as stable?
> > > > > > I know it's planned for 5.2, but I have no idea about the current
> > > > state.
> > > > > >
> > > > >
> > > > > We ideally produce Python 2 and Python 3 package variants. Then we
> > switch
> > > > > to Python 3 exclusive in a future release.
> > > > >
> > > > > For Debian packaging, this could be a bit more difficult, as I
> > believe
> > > > we'd
> > > > > need to fork the Debian packaging templates in the repository.
> > > >
> > > > Maybe python-mercurial package can be split off so we can generate both
> > > > python-mercurial and python3-mercurial. The main mercurial package will
> > > > have
> > > > to depend on one of these, but we can at least run python|python3
> > > > /usr/bin/hg.
> > > >
> > >
> > > What's the advantage of that?
> >
> > I can run "python /usr/bin/hg".
> >
> > > You mean that tortoisehg would depend on
> > > python-mercurial only?
> >
> > Kind of. tortoisehg will have to depend on python(2)-mercurial for
> > in-process
> > dependency, and mercurial for command-server stuff.
> >
> > > And the main mercurial package would also contain any native code then,
> > > right? Or is that compatible across Python versions?
> >
> > The entry-point script and misc files will be included in the main package.
> >
> > Anyway, splitting packages might be good for the official packages, but it
> > shouldn't be required for ours. Doing that might complicate our packaging
> > scripts.
> >
> 
> I strongly believe that our official packages should be a unified .deb that
> someone can download + `dpkg -i` to install it. Multiple packages just
> complicates things for downstream consumers.

We already have mercurial (binary-arch) and mercurial-common (binary-indep).
Maybe they can be unified by adding some conflicts/breaks fields.


More information about the Mercurial-devel mailing list