On Mon, 21 Oct 2019 19:13:48 -0700, Gregory Szorc wrote: > On Mon, Oct 21, 2019 at 6:26 PM Yuya Nishihara <y...@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 <y...@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 <y...@tcha.org> > > wrote: > > > > > > On Mon, 21 Oct 2019 12:00:55 +0200, Denis Laxalde wrote: > > > > > > > # HG changeset patch > > > > > > > # User Denis Laxalde <de...@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. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
