skalibs debian package update

From: Markus Sauermann <sauermann_at_disroot.org>
Date: Sun, 29 Mar 2026 21:37:16 +0200

Hello Laurent,

I'm trying to create an updated debian package of skalibs, because the
currently available version 2.14.3.0 from 2024 is rather outdated and
not compatible with s6-frontend.

I'm running into two difficulties, where I hope to get help here.

1. usage of rpath

In the Makefile `-Wl,-rpath=$(dynlibdir)` is used. This option was
introduced in
https://git.skarnet.org/cgi-bin/cgit.cgi/skalibs/commit/?id=6348137adc2e0d2914339e760dbde1814d44b109

However the usage of rpath leads to problems during Debian package
creation and is discouraged in Debian according to
https://wiki.debian.org/RpathIssue

Would you be willing to include an option in the `configure` script to
allow building the library wihtout rpath?
I have tested, that the following implementation works for me:

=== BEGIN DIFF ===
diff --git a/Makefile b/Makefile
index d1af3ec..2264a91 100644
--- a/Makefile
+++ b/Makefile
_at__at_ -138,7 +138,7 _at__at_ libskarnet.a.xyzzy: $(ALL_SOBJS)
         exec $(RANLIB) $_at_

  libskarnet.so.xyzzy: $(ALL_DOBJS)
- exec $(CC) -o $_at_ $(CFLAGS_ALL) $(CFLAGS_SHARED) $(LDFLAGS_ALL)
$(LDFLAGS_SHARED) -Wl,-soname,libskarnet.so.$(version_M)
-Wl,-rpath=$(dynlibdir) $^ $(SYSTEM_LIBS)
+ exec $(CC) -o $_at_ $(CFLAGS_ALL) $(CFLAGS_SHARED) $(LDFLAGS_ALL)
$(LDFLAGS_SHARED) -Wl,-soname,libskarnet.so.$(version_M)
$(LDFLAGS_RPATH) $^ $(SYSTEM_LIBS)

  libskarnet.pc:
         exec env \
diff --git a/configure b/configure
index 453589f..8eeb76e 100755
--- a/configure
+++ b/configure
_at__at_ -40,6 +40,7 _at__at_ Optional features:
    --disable-all-pic do not build static libraries as PIC
[enabled]
    --enable-slashpackage[=ROOT] assume /package installation at ROOT
[disabled]
    --enable-pkgconfig Build and install .pc files for
pkg-config [disabled]
+ --disable-rpath do not include rpath in libraries [enabled]

  $package tuning options:
    --disable-ipv6 do not build IPv6 support [enabled]
_at__at_ -404,6 +405,7 _at__at_ shared=true
  static=true
  allpic=true
  slashpackage=false
+rpath=true
  ipv6=true
  select=false
  taiclock=false
_at__at_ -448,6 +450,8 _at__at_ for arg ; do
      --enable-slashpackage=*) sproot=${arg#*=} ; slashpackage=true ; ;;
      --enable-slashpackage) sproot= ; slashpackage=true ;;
      --disable-slashpackage) sproot= ; slashpackage=false ;;
+ --enable-rpath|--enable-rpath=yes) rpath=true ;;
+ --disable-rpath|--enable-rpath=no) rpath=false ;;
      --enable-ipv6|--enable-ipv6=yes) ipv6=true ;;
      --disable-ipv6|--enable-ipv6=no) ipv6=false ;;
      --enable-iopause-select|--enable-iopause-select=yes) select=true ;;
_at__at_ -803,6 +807,11 _at__at_ if $allpic ; then
  else
    echo "STATIC_LIBS_ARE_PIC :="
  fi
+if $rpath ; then
+ echo "LDFLAGS_RPATH := -Wl,-rpath=${dynlibdir}"
+else
+ echo "LDFLAGS_RPATH :="
+fi

  exec 1>&3 3>&-
  echo " ... done."
=== END DIFF ===


2. API breaking changes

During 2.14.4.0 and 2.14.5.0, the removal of `skalibs_sigtable` caused
an API breaking change in
https://git.skarnet.org/cgi-bin/cgit.cgi/skalibs/commit/?id=32ac3aa6ac8f0dc9a240611a3696c0e5510b841d

API breaking changes make a more complex process necessary for debian
package updates.

Have you thought about restricting future API breaking changes to major
version updates (e.g. from v2 to v3)? If that is not feasible for you, I
would kindly ask you to consider at least, to do such breaking changes
only during minor version updates (eg. from v2.14 to v2.15) in the future.

The reason for this request is, that a breaking change between 2.14.4.0
and 2.14.5.0 makes it necessary to create a new soname like 2.14a (which
corresponds to v2.14.5.0) in order to distinguish it from 2.14 (which
corresponds to v2.14.4.0), because they are API-incompatible. To achieve
this change, the only solution I found until now was to patch the
buildscript in order to create the adjusted soname, which seems rather
like a hack to me.


Please let me know, what you think about these two ideas.

Best wishes
Markus
Received on Sun Mar 29 2026 - 21:37:16 CEST

This archive was generated by hypermail 2.4.0 : Sun Mar 29 2026 - 21:37:47 CEST