On Mon, Mar 30, 2026 at 5:47 PM Markus Sauermann via skaware
<skaware_at_list.skarnet.org> wrote:
>
> Hi Laurent,
>
> thank you for the answer.
>
> On 2026-03-30 00:22, Laurent Bercot wrote:
> > What exact problems are you experiencing during package creation?
>
> The actual problem is, that after the package is successfully built, the
> Debian Lintian system throws a custom-library-search-path error.
> https://lintian.debian.org/tags/custom-library-search-path.html
> Basically the debian policy discourages the use of rpath except in
> certain situations, which do not apply here.
>
> > Some skaware packages already exist for Debian, they do not turn off rpath,
> > and they're working, as far as I can tell.
>
> I have checked skalibs, execline and s6: rpath was introduced in spring
> 2025 to their Makefiles. Since the current skaware Debian packages were
> built in 2024, that topic didn't come up yet.
> This means, that this Lintian policy will also affect the other skaware
> Debian packages, when they get updated.
>
OpenEmbedded does QA checks for embedded rpaths which match the defaults:
https://docs.yoctoproject.org/ref-manual/qa-checks.html#useless-rpaths
The builds I used in an embedded project back then triggered them.
> > [...]
> > I am reluctant to provide an option to disable rpath because in my
> > experience, disabling it can cause linking failure annoyances at every
> > step, whereas keeping it enable only causes problems when something is
> > already wrong either in a build or in versioning management of a package.
> > If Debian can do without that option, and so far it looks like it has
> > been able to, I'd rather keep it that way.
>
> Thanks for the explanation. I will investigate alternatives like
> patching the Makefile or using chrpath. Such a config option seemed to
> me like the cleanest and most future proof way to solve this.
>
chrpath was how I worked around it.
--
Alex Kiernan
Received on Mon Mar 30 2026 - 20:05:22 CEST