Path: csiph.com!aioe.org!bofh.it!news.nic.it!robomod
From: Julian Gilbey <julian@d-and-j.net>
Newsgroups: linux.debian.maint.python
Subject: Re: Build and run-time triplets
Date: Thu, 09 Jun 2022 11:00:01 +0200
Message-ID: <Ewmbf-3CSM-3@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>
X-Original-To: Andrey Rahmatullin <wrar@debian.org>
X-Mailbox-Line: From debian-python-request@lists.debian.org  Thu Jun  9 08:56:57 2022
Old-Return-Path: <julian@d-and-j.net>
X-Amavis-Spam-Status: No, score=-7.11 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FOURLA=0.1, LDO_WHITELIST=-5, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
X-Policyd-Weight: using cached result; rate:hard: -4.6
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Mailing-List: <debian-python@lists.debian.org> archive/latest/20000
List-ID: <debian-python.lists.debian.org>
List-URL: <https://lists.debian.org/debian-python/>
List-Archive: https://lists.debian.org/msgid-search/YqG1yvivv+THiRgu@d-and-j.net
Approved: robomod@news.nic.it
Lines: 38
Organization: linux.* mail to news gateway
Sender: robomod@news.nic.it
X-Original-Cc: debian-python@lists.debian.org
X-Original-Date: Thu, 9 Jun 2022 09:56:42 +0100
X-Original-Message-ID: <YqG1yvivv+THiRgu@d-and-j.net>
X-Original-References: <YqEYHQLYKvGFmSAa@d-and-j.net> <YqGR3t+65uPJGTxk@belkar.wrar.name> <YqGkZDt/2GKkJV1l@d-and-j.net> <YqGpTXvqVuCglMqB@belkar.wrar.name>
Xref: csiph.com linux.debian.maint.python:14172

On Thu, Jun 09, 2022 at 01:03:25PM +0500, Andrey Rahmatullin wrote:
> [...]
> > 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 both
> 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 system
> used. For the run time, https://wiki.debian.org/Python/MultiArch suggests
> 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. 

Thanks for your help!

OK (and yes, it does require the full path at runtime).  What triplet
do I use in d/rules?  dpkg-architecture offers 6 different ones:
DEB_{BUILD,HOST,TARGET}_{GNU_TYPE,MULTIARCH}?  I'm guessing
DEB_TARGET_MULTIARCH, but I'm really not certain, so it would be great
to confirm that.

About the location, though: why do compiled Python libraries live in
/usr/lib/python3/dist-packages/<pkgname> and not
/usr/lib/<triplet>/<pkgname>?  And is there a good reason not to do
the same with this Python-package-specific library?  It's not for
general use, so I can't see why I shouldn't put it in the python3
directory with the other compiled Python module libraries.

Best wishes,

   Julian