<div dir="ltr"><div>You're right that the technique is the same -- bundled glibc, patched interpreter and rpath. </div><div>I took $ORIGIN and the patch-everything loop from your script. </div><div>The difference isn't technical, it's what each one asks the repo for.</div><br><div>Yours needs a second thing to exist: either a glibc-opt-bin SlackBuild in the repo, or the user runs your apply script by hand. </div><div>That's what Willy refused -- not the patching, but adding a shared glibc to SBo that other scripts could then depend on.</div><div> He called it all or nothing, and he was right about that: </div><div>once glibc-opt-bin exists in the repo, it's a package the admins have to maintain, and your own message anticipated other packages following the same pattern.</div><br><div>Now doesn't create anything shared. The .txz is a build-time source, extracted into the package payload the same way any tarball is. </div><div>What gets installed is a set of .so files under /opt/Signal/signal-desktop/lib64/, reachable only through one binary's PT_INTERP and DT_RPATH. </div><div>No second package, no REQUIRES, nothing on the system another script could ever link against.</div><div> It's vendored libraries in one package, which SBo already accepts elsewhere.</div><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 /opt/glibc left behind<br>- survives upgradepkg, because the patching is in the SlackBuild rather than something to re-run afterwards<br>- the source has an md5sum in the .info, instead of required a glibc 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 becomes "can one package carry private libraries under /opt", which is a much smaller question.<br><br>Its like you run an independent signal-desktop.AppImage with the required glibc included :)</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Στις Πέμ 13 Αυγ 2026 στις 7:26 μ.μ., ο/η Lumin Etherlight via SlackBuilds-users <<a href="mailto:slackbuilds-users@slackbuilds.org">slackbuilds-users@slackbuilds.org</a>> έγραψε:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yiannis <<a href="mailto:rizitis@gmail.com" target="_blank">rizitis@gmail.com</a>> writes:<br>
<br>
> Just  to  be  clear,  this  is  not  the  same  as<br>
> installing  the  testing  glibc.  Nothing  on  the<br>
> system  changes.  System   glibc  stays  2.33.  No<br>
> upgradepkg of  a core  package, no  ld.so.conf, no<br>
> ldconfig.<br>
><br>
> What the script does:<br>
><br>
> - unpacks the snap into /opt/Signal/signal-desktop<br>
> - unpacks  aaa_glibc-solibs-2.42  into  the  same<br>
>   prefix, as a build source like any tarball<br>
> - patchelf on the Electron binary so its PT_INTERP<br>
>   and DT_RPATH point there<br>
<br>
        I don't see how this differs in a meaningful<br>
  way from the existing solution that was refused by<br>
  the SBo admins.  The only minor difference is that<br>
  you're extracting Signal from  a snap instead of a<br>
  .deb archive.  The testing glibc is installed into<br>
  /opt, and Signal binaries  are patched to point to<br>
  that glibc instead of  the system one.  If there's<br>
  some  other important  difference here,  please do<br>
  explain it a bit more.<br>
<br>
Best Regards,<br>
Lumin Etherlight<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>