Path: csiph.com!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod
From: Andrey Rahmatullin <wrar@debian.org>
Newsgroups: linux.debian.maint.python
Subject: Re: Build and run-time triplets
Date: Sun, 24 Jul 2022 20:50:01 +0200
Message-ID: <EMOPT-dzto-9@gated-at.bofh.it>
References: <EwbIR-3wrn-9@gated-at.bofh.it> <EwjQ5-3Bsn-7@gated-at.bofh.it> <Ewl5v-3Cb5-7@gated-at.bofh.it> <EwloR-3Cz8-5@gated-at.bofh.it> <EMNK9-dyR6-5@gated-at.bofh.it>
X-Mailbox-Line: From debian-python-request@lists.debian.org  Sun Jul 24 18:42:15 2022
Old-Return-Path: <wrar@debian.org>
X-Amavis-Spam-Status: No, score=-12.01 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, LDO_WHITELIST=-5, PGPSIGNATURE=-5, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
X-Policyd-Weight: using cached result; rate: -3.5
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ug5zeiHp+r4dXcjV"
Content-Disposition: inline
X-Mailing-List: <debian-python@lists.debian.org> archive/latest/20107
List-ID: <debian-python.lists.debian.org>
List-URL: <https://lists.debian.org/debian-python/>
List-Archive: https://lists.debian.org/msgid-search/Yt2SdIhrSwjVd8sQ@belkar.wrar.name
Approved: robomod@news.nic.it
Lines: 94
Organization: linux.* mail to news gateway
Sender: robomod@news.nic.it
X-Original-Date: Sun, 24 Jul 2022 23:41:56 +0500
X-Original-Message-ID: <Yt2SdIhrSwjVd8sQ@belkar.wrar.name>
X-Original-References: <YqEYHQLYKvGFmSAa@d-and-j.net> <YqGR3t+65uPJGTxk@belkar.wrar.name> <YqGkZDt/2GKkJV1l@d-and-j.net> <YqGpTXvqVuCglMqB@belkar.wrar.name> <Yt2DOYXK8jhY6faA@d-and-j.net>
Xref: csiph.com linux.debian.maint.python:14274


--ug5zeiHp+r4dXcjV
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 24, 2022 at 06:36:57PM +0100, Julian Gilbey wrote:
> > > > > I'd like to ask for some help.  I'm working on packaging pydevd, =
which
> > > > > builds a private .so library.  Ordinary extensions built using cy=
thon
> > > > > or similar end up being called "foo.cpython-310-x86_64-linux-gnu.=
so",
> > > > > but this library, which is not dependent on the Python version, s=
hould
> > > > > presumably be called "bar.x86_64-linux-gnu.so".
> > > > If it's just a private library and not a Python module it should be=
 called
> > > > bar.so.
> > > >=20
> > > > > Question 1: How do I determine (within Python) the triplet to use=
 when
> > > > > building the library?
> > > > You don't.
> > > >=20
> > > > > Question 2: How do I determine (within Python) the triplet to use=
 when
> > > > > loading the library at runtime?
> > > > You don't, but also how are you actually loading it?
> > >=20
> > > Well, the upstream wanted to compile two versions of the library, one
> > > for 64 bit architectures and one for 32 bit architectures.  I don't
> > > really want to build two different arch libraries in a single build,
> > > because that seems very contrary to the way the Debian architectures
> > > work, and would also limit it to the amd64/i386 architectures for no
> > > obviously good reason.  I had imagined that if there is some sort of
> > > multiarch setup, one might have the amd64 and i386 packages installed
> > > simultaneously, hence the need for different names.
> > The normal way for this is putting it into
> > /usr/lib/<triplet>/pkgname/foo.so, and according to the code below you'=
ll
> > need the full path at the run time so you indeed need the triplet at bo=
th
> > build and run time. You can get the triplet in d/rules, not sure how
> > should you pass it to the build system as that depends on the build sys=
tem
> > used. For the run time, https://wiki.debian.org/Python/MultiArch sugges=
ts
> > sys.implementation._multiarch (note that you cannot use it during the
> > build as that would break cross-compilation etc.), not sure if there are
> > better ways.=20
>=20
> I got all of the triplets working, but was then stymied when I tried
> to specify Multi-Arch: same in the control file.  I got a lintian
> warning: multi-arch-same-package-calls-pycompile
> It seems that since the pybuild system (via dh_python3) adds a
> py3compile command to the postinst of the package, then I can't safely
> use Multi-Arch: same.
>=20
> I don't know if this is the case for all python3 Arch: any packages
> with compiled extensions;
I think the tag desciption has a good step-by-step explanation why does
the tag exists.
But your package is not a "package with compiled extensions", is it?

> are they all effectively Multi-Arch: no?  Is this worth thinking about
> in the longer term?
What do you propose?

--=20
WBR, wRAR

--ug5zeiHp+r4dXcjV
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmLdknAtFIAAAAAAFQAP
cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh
8t8QAKNU2H1EYKVF5ze3j9NhzVpqPKu+JJzmmX6njiWY/DMCv+E1KDm59F2rzP1L
ytTtEfRohgTDUlS9UYLY3e2970eqoUw9ZwGcHpB2tJXKIDvbrK0i/2gf2L98WcEh
utIowBdYSJerF+r7o9BXrcITC98f+Z1lrKT/YQ7CI2WedgkVRhk1UavN34vVChvW
wh/ax1eTHJyKdCngY8+XvDd7q3vZutcFdioj+Ep7h3w7FpZNEDfOini6vNUuAo//
RQhVMhSjqvcnDN2+17SJI5MJFBWD4NDbqIljvL4Y4rKn7a8Q0bF9jbikTTy7NlPn
kSqBM217yqOC50GvBg2PZl8zTPkkCZn7TyXOsjZsr5sOtHth7N9J0hyNzD46y/p+
7HIPhLmnJaviJ5GVmqFr5nGu+HzgwOG3DP37juwifHrzDvbfQscsj3MuacXyRzLJ
ZuWRtLQS1UtHeDailuZg8EwaoavTjfAbZ8ylkusQqnarzn6YEwZy74oZu5XgAUxS
8mmkLuU5Rg8cZ5wZbe95YT32s0xShJvMY7Q7bA/CHmOtXy0bZYdVOp4X0PpsRYxv
NIgn03LJ6F3nlb572Uc4jJ+PK9kpscez4Gg32qHrnXsMgZqnHUAlLjpAIWQXOK/c
SxABfkB3dG0vV/uiRXIrKsZkuctbkmZlmHIdcOxU9sfs0pWg
=0YRy
-----END PGP SIGNATURE-----

--ug5zeiHp+r4dXcjV--