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

Gregory Szorc gregory.szorc at gmail.com
Mon Oct 21 22:13:48 EDT 2019


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20191021/b90f626c/attachment.html>


More information about the Mercurial-devel mailing list