Well, turns out that apparently nobody else bothers with a .symbols file
for Python extensions. I looked at the packages for samba, numpy, mypy and
python-stdlib-extensions. And if the Python maintainers themselves don't do
it, you probably shouldn't.
I attached a diff to remove the relevant file and the setup for it. I also
added some verbosity to the stuff debhelper does (I find it harder to debug
build issues without it).
I verified that except for this symbols file going away, nothing else
changed. (Most notable, the main libldb-dev package still looks the same.)
- Verified via diffoscope which only showed expected changes (timestamps,
mostly)
I'll see if I can turn it into a pull request on Salsa, but my git-foo
is weaker than it probably should be, so feel free to just apply my patch
yourself.
If I create a pull request, should that include an update to
debian/changelog?
Cheers,
Sven
Am Do., 17. Dez. 2020 um 16:55 Uhr schrieb Mathieu Parent <
math.par...@gmail.com>:
> Le jeu. 17 déc. 2020 à 16:48, Sven Mueller a
> écrit :
> >
> > Hi Mathieu.
>
> Hi,
>
> > Just wanted to say that your fix here seems wrong:
> > The symbols file says when a specific symbol for a specific lib was
> added.
> > If I rebuild ldb against Python 3.9, it will suddenly claim that - for
> example - symbol PYLDB_UTIL_2.1.0@PYLDB_UTIL_2.1.0 was added to the
> package - for the Python 3.9 specific lib - in package version 2:2.1.0 -
> Even though that package version was not built against Python 3.9 at all.
> >
> > The better fix would be to explicitly build against specific Python
> versions (python3.8-dev, python3.9-dev build dependencies) and have
> appropriate symbols listed for both of them.
> >
> > Currently, if a package builds against the ldb python bindings for
> Python 3.9, it will generate versioned dependencies that are incorrect (if
> all it uses would be the above symbol, it would depend on python3-ldb >=
> 2:2.1.0 - which didn't have any Python 3.9 bindings) - and fail after
> installation.
> >
> > To be fair though, I'm not even sure having the symbols file for the
> python bindings .so files makes much sense.
>
> OK. Could you submit a merge request fixing this? SInce the migration
> to python3, the bindings are getting complicated. Any help here is
> apprecciated.
>
> Regards
>
> Mathieu Parent
>
diff -urN ldb-2.2.0.orig/debian/python3-ldb.symbols.in ldb-2.2.0/debian/python3-ldb.symbols.in
--- ldb-2.2.0.orig/debian/python3-ldb.symbols.in 2020-12-21 13:23:55.062566080 +0100
+++ ldb-2.2.0/debian/python3-ldb.symbols.in 1970-01-01 01:00:00.0 +0100
@@ -1,63 +0,0 @@
-#!/usr/bin/dh-exec
-libpyldb-util${DEB_PY3_EXTENSION_SUFFIX}.2 python3-ldb #MINVER#
- PYLDB_UTIL${DEB_PY3_EXTENSION_UPCASE}_2.2.0@PYLDB_UTIL${DEB_PY3_EXTENSION_UPCASE}_2.2.0 2:2.2.0
-#include "python3-ldb.symbols.common" PYLDB_UTIL_1.1.2@PYLDB_UTIL_1.1.2 2:2.0.7
- PYLDB_UTIL_1.1.2@PYLDB_UTIL_1.1.2 2:2.2.0
- PYLDB_UTIL_1.1.3@PYLDB_UTIL_1.1.3 2:2.0.7
- PYLDB_UTIL_1.1.4@PYLDB_UTIL_1.1.4 2:2.0.7
- PYLDB_UTIL_1.1.5@PYLDB_UTIL_1.1.5 2:2.0.7
- PYLDB_UTIL_1.1.6@PYLDB_UTIL_1.1.6 2:2.0.7
- PYLDB_UTIL_1.1.7@PYLDB_UTIL_1.1.7 2:2.0.7
- PYLDB_UTIL_1.1.8@PYLDB_UTIL_1.1.8 2:2.0.7
- PYLDB_UTIL_1.1.9@PYLDB_UTIL_1.1.9 2:2.0.7
- PYLDB_UTIL_1.1.10@PYLDB_UTIL_1.1.10 2:2.0.7
- PYLDB_UTIL_1.1.11@PYLDB_UTIL_1.1.11 2:2.0.7
- PYLDB_UTIL_1.1.12@PYLDB_UTIL_1.1.12 2:2.0.7
- PYLDB_UTIL_1.1.13@PYLDB_UTIL_1.1.13 2:2.0.7
- PYLDB_UTIL_1.1.14@PYLDB_UTIL_1.1.14 2:2.0.7
- PYLDB_UTIL_1.1.15@PYLDB_UTIL_1.1.15 2:2.0.7
- PYLDB_UTIL_1.1.16@PYLDB_UTIL_1.1.16 2:2.0.7
- PYLDB_UTIL_1.1.17@PYLDB_UTIL_1.1.17 2:2.0.7
- PYLDB_UTIL_1.1.18@PYLDB_UTIL_1.1.18 2:2.0.7
- PYLDB_UTIL_1.1.19@PYLDB_UTIL_1.1.19 2:2.0.7
- PYLDB_UTIL_1.1.20@PYLDB_UTIL_1.1.20 2:2.0.7
- PYLDB_UTIL_1.1.21@PYLDB_UTIL_1.1.21 2:2.0.7
- PYLDB_UTIL_1.1.22@PYLDB_UTIL_1.1.22 2:2.0.7
- PYLDB_UTIL_1.1.23@PYLDB_UTIL_1.1.23 1.5.4
- PYLDB_UTIL_1.1.24@PYLDB_UTIL_1.1.24 1.5.4
- PYLDB_UTIL_1.1.25@PYLDB_UTIL_1.1.25 1.5.4
- PYLDB_UTIL_1.1.26@PYLDB_UTIL_1.1.26 1.5.4
- PYLDB_UTIL_1.1.27@PYLDB_UTIL_1.1.27 1.5.4
- PYLDB_UTIL_1.1.28@PYLDB_UTIL_1.1.28 1.5.4
- PYLDB_UTIL_1.1.29@PYLDB_UTIL_1.1.29 1.5.4
- PYLDB_UTIL_1.1.30@PYLDB_UTIL_1.1.30 1.5.4
- PYLDB_UTIL_1.1.31@PYLDB_UTIL_1.1.31 1.5.4
- PYLDB_UTIL_1.2.0@PYLDB_UTIL_1.2.0 1.5.4
- PYLDB_UTIL_1.2.1@PYLDB_UTIL_1.2.1 1.5.4
- PYLDB_UTIL_1.2.2@PYLDB_UTIL_1.2.2 1.5.4
- PYLDB_UTIL_1.2.3@PYLDB_UTIL_1.2.3 1.5.4
- PYLDB_UTIL_1.3.0@PYLDB_UTIL_1.3.0 1.5.4
- PYLDB_UTIL_1.3.1@PYLDB_UTIL_1.3.1 1.5.4
- PYLDB_UTIL_1.3.2@PYLDB_UTIL_1.3.2 1.5.4
- PYLDB_UTIL_1.4.0@PYLDB_UTIL_1.4.0 1.5.4
- PYLDB_UTIL_1.4.1@PYLDB_UTIL_1.4.1 1.5.4
- PYLDB_UTIL_1.5.0@PYLDB_UTIL_1.5.0 1.5.4
- PYLDB_UTIL_1.5.1@PYLDB_UTIL_1.5.1 1.5.4
- PYLDB_UTIL_1.5.2@PYLDB_UTIL_1.5.2 1.5.4
- PYLDB_UTIL_1.5.3@PYLDB_UTIL_1.5.3 1.5.4
- PYLDB_UTIL_1.6.0@PYLDB_UTIL_1.6.0 2:2.0.7
- PYLDB_UTIL_1.6.1@PYLDB_UTIL_1.6.1 2:2.0.7
- PYLDB_UTIL_1.6.2@PYLDB_UTIL_1.6.2 2:2.0.7
- PYLDB_UTIL_1.6.3@PYLDB_UTIL_1.6.3 2:2.0.7
- PYLDB_UTIL_2.0.0@PYLDB_UTIL_2.0.0 2:2.0.7
-
