On Wed, Mar 02 2022, aisha <openbsd.po...@aisha.cc> wrote: > On 2/27/2022 8:55 AM, Jeremie Courreges-Anglas wrote: >> On Sat, Feb 26 2022, Stuart Henderson <s...@spacehopper.org> wrote: >>> On 2022/02/26 17:15, Kurt Mosiejczuk wrote: >>>> On Sat, Feb 26, 2022 at 11:55:46AM -0500, aisha wrote: >>>>> Hi, >>>>> I've attached a port for py-libknot which allows >>>>> a much better control for knot through scripting rather >>>>> than parsing the knotc(8) output. Plus this is >>>>> maintained by the knot team and in the same repository >>>>> as knot so it should be (and imo is) pretty stable. >>>>> Port made with `portgen py libknot`. >>>> Since it is a library, it shouldn't use MODPY_DEFAULT_VERSION_3 (which is >>>> now the default anyway) it should use FLAVORS=python3 and FLAVOR=python3. >>>> >>>> With that changed, ok kmos for import >>>> >>>> --Kurt >>>> >>> I do wonder if it might be better to build this in net/knot instead >>> (the files are in the main knot distfile too) and subpackage it. >> The main knot tarball doesn't come with the generated setuptools glue. >> So I'm not sure how to get the same resulting python package as >> a subpackage of net/knot. Certainly doable, but I can only think of >> hacks. > > There's a few more problems with that, even the pregenerated setuptools > files need > patching as they don't load the correct shared library by default. The > port I had previously > attached did not load the correct shared library as there was no way to > keep track of > what version is installed by net/knot. The subpackage setup could solve > that more easily.
As noted by sthen@ this easily fixed by just patching away the version
number. We don't respect upstreams' shared library versioning anyway,
so it's not the first time we hit a port that wants a particular
upstream version number.
It's worth mentioning that this python package uses ctypes and
not a .so python module linking against libknot.so.X.Y. So the ABI
requirements are looser, and enforcing in ports a tighter requirement on
a particular libknot.so.X.Y appears artificial. It seems easier to
add a strict requirement on the full net/knot version and keep that in
sync.
>>> I suspect it may be a fairly tight dependency so they probably will need
>>> handling together in updates.
>> Implementing tight requirements can be done in a separate port too
>> (something like RUN_DEPENDS = net/knot=${MODPY_EGG_VERSION} ?).
>> Probably better than a forced LIB_DEPENDS / WANTLIB setup.
>>
>> I agree with kmos@ regarding MODPY_DEFAULT_VERSION_3
>>
>>> Pinging jca@ (net/knot maintainer) for any comments ..
>> FWIW I would gladly leave maintainership of net/knot to someone else, as
>> I don't actually use knot on a daily basis. Or I can help
>> co-maintaining this. ;)
>
> I'd be happy to co-maintain it, I use it regularly enough to invest time
> in this port.
>
> But I'm not sure how to proceed currently, any pointers on how to make
> a subpackage setup?
See "FLAVORS AND MULTI_PACKAGES" in bsd.port.mk(5).
As far as I'm concerned I'm not interested in spending time on finding
the right setuptools recipe to replicate what would be already
available in the standalone tarball shipped on pypi. Same for
MASTER_SITES etc as provided by python.port.mk. *Maybe* it would be
easier to use a MULTI_PACKAGES setup if upstream shipped the main knot
tarballs with the same setuptools goo as the tarball shipped on pypi.
So as far as I'm concerned, here's how I would propose to go forward:
keep py-libknot as a separate port but with a tight requirement on
net/knot. I don't see the point in adding devel to CATEGORIES.
Diff to previous below and updated tarball attached.
diff -pruN py-libknot.orig/Makefile py-libknot/Makefile
--- py-libknot.orig/Makefile Sat Feb 26 17:37:43 2022
+++ py-libknot/Makefile Thu Mar 3 22:34:55 2022
@@ -2,12 +2,13 @@
COMMENT = Python bindings for libknot
+# keep in sync with net/knot
MODPY_EGG_VERSION = 3.1.6
DISTNAME = libknot-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
-CATEGORIES = net devel
+CATEGORIES = net
HOMEPAGE = https://gitlab.nic.cz/knot/knot-dns
@@ -20,8 +21,9 @@ MODULES = lang/python
MODPY_PI = Yes
MODPY_SETUPTOOLS = Yes
-MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
+FLAVORS = python3
+FLAVOR = python3
-RUN_DEPENDS = net/knot
+RUN_DEPENDS = net/knot=${MODPY_EGG_VERSION}
.include <bsd.port.mk>
diff -pruN py-libknot.orig/patches/patch-libknot___init___py
py-libknot/patches/patch-libknot___init___py
--- py-libknot.orig/patches/patch-libknot___init___py Thu Jan 1 01:00:00 1970
+++ py-libknot/patches/patch-libknot___init___py Sun Feb 27 23:20:49 2022
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Don't hardcode libknot.so version number.
+
+Index: libknot/__init__.py
+--- libknot/__init__.py.orig
++++ libknot/__init__.py
+@@ -46,7 +46,7 @@ class Knot(object):
+ if sys.platform == "darwin":
+ path = "libknot%s.dylib" % version
+ else:
+- path = "libknot.so%s" % version
++ path = "libknot.so"
+
+ cls.LIBKNOT = ctypes.cdll.LoadLibrary(path)
+
py-libknot.1.tgz
Description: Binary data
-- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
