<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small">Thanks all,</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small">I have pushed a PR on codeberg to update signal-desktop to the lastest version which include the workaround for -stable vanilla. The script test for the version of glibc and only apply the workaround if the system is running too old a version.</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small"><a href="https://codeberg.org/ArTourter/slackbuilds/commit/c2e89a3839433860355bf387e51228c85615126b">https://codeberg.org/ArTourter/slackbuilds/commit/c2e89a3839433860355bf387e51228c85615126b</a></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small"><a href="https://codeberg.org/SlackBuildsOrg/slackbuilds/pulls/34">https://codeberg.org/SlackBuildsOrg/slackbuilds/pulls/34</a></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small">Let me know if something is not working as expect on your system.</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small">Cheers</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small">Greg</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, 14 Aug 2026 at 02:14, Willy Sudiarto Raharjo <<a href="mailto:willysr@slackbuilds.org">willysr@slackbuilds.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>You're right that the technique is the same -- bundled glibc, patched<br>
>interpreter and rpath.<br>
>I took $ORIGIN and the patch-everything loop from your script.<br>
>The difference isn't technical, it's what each one asks the repo for.<br>
><br>
>Yours needs a second thing to exist: either a glibc-opt-bin SlackBuild<br>
>in the repo, or the user runs your apply script by hand.<br>
>That's what Willy refused -- not the patching, but adding a shared<br>
>glibc to SBo that other scripts could then depend on.<br>
> He called it all or nothing, and he was right about that:<br>
>once glibc-opt-bin exists in the repo, it's a package the admins have<br>
>to maintain, and your own message anticipated other packages following<br>
>the same pattern.<br>
><br>
>Now doesn't create anything shared. The .txz is a build-time source,<br>
>extracted into the package payload the same way any tarball is.<br>
>What gets installed is a set of .so files under<br>
>/opt/Signal/signal-desktop/lib64/, reachable only through one binary's<br>
>PT_INTERP and DT_RPATH.<br>
>No second package, no REQUIRES, nothing on the system another script<br>
>could ever link against.<br>
> It's vendored libraries in one package, which SBo already accepts<br>
>elsewhere.<br>
><br>
>Concretely, from a user's point of view:<br>
><br>
>- installpkg and it works; no apply step<br>
>- removepkg takes all of it, including the glibc; no revert step, no<br>
>/opt/glibc left behind<br>
>- survives upgradepkg, because the patching is in the SlackBuild rather<br>
>than something to re-run afterwards<br>
>- the source has an md5sum in the .info, instead of required a glibc<br>
>package<br>
>- system glibc stays 2.33 and no other package sees 2.42<br>
><br>
>So the question for the admins stops being "can SBo ship a glibc" and<br>
>becomes "can one package carry private libraries under /opt", which is<br>
>a much smaller question.<br>
><br>
>Its like you run an independent signal-desktop.AppImage with the<br>
>required glibc included :)<br>
<br>
>From my *personal perspective*, this approach is fine since it's<br>
contained *only* for this spesific package, so we can keep using the<br>
original GLIBC from Slackware 15.0.<br>
It's like how alienBOB provide some of his package where all<br>
modules/dependencies are linked statically into his single package<br>
without linking to outside libraries.<br>
<br>
the disadvantages of this approach is that the output package will be<br>
slightly bigger in size<br>
<br>
<br>
--<br>
Willy Sudiarto Raharjo<br>
_______________________________________________<br>
SlackBuilds-users mailing list<br>
<a href="mailto:SlackBuilds-users@slackbuilds.org" target="_blank">SlackBuilds-users@slackbuilds.org</a><br>
<a href="https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="https://lists.slackbuilds.org/pipermail/slackbuilds-users/" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="https://slackbuilds.org/faq/" rel="noreferrer" target="_blank">https://slackbuilds.org/faq/</a><br>
<br>
</blockquote></div>