[PATCH 3 of 6] packaging: upgrade Debian packaging to build with Python 3
yuya at tcha.org
Mon Oct 21 21:26:17 EDT 2019
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
More information about the Mercurial-devel