[Slackbuilds-users] Build Environment Reminder

[Yiannis]

You're right that the technique is the same -- bundled glibc, patched
interpreter and rpath.
I took $ORIGIN and the patch-everything loop from your script.
The difference isn't technical, it's what each one asks the repo for.

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.
That's what Willy refused -- not the patching, but adding a shared glibc to
SBo that other scripts could then depend on.
 He called it all or nothing, and he was right about that:
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.

Now doesn't create anything shared. The .txz is a build-time source,
extracted into the package payload the same way any tarball is.
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.
No second package, no REQUIRES, nothing on the system another script could
ever link against.
 It's vendored libraries in one package, which SBo already accepts
elsewhere.

Concretely, from a user's point of view:

- installpkg and it works; no apply step
- removepkg takes all of it, including the glibc; no revert step, no
/opt/glibc left behind
- survives upgradepkg, because the patching is in the SlackBuild rather
than something to re-run afterwards
- the source has an md5sum in the .info, instead of required a glibc package
- system glibc stays 2.33 and no other package sees 2.42

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.

Its like you run an independent signal-desktop.AppImage with the required
glibc included :)

Στις Πέμ 13 Αυγ 2026 στις 7:26 μ.μ., ο/η Lumin Etherlight via
SlackBuilds-users <slackbuilds-users at slackbuilds.org> έγραψε:

> Yiannis <rizitis at gmail.com> writes:
>
> > Just  to  be  clear,  this  is  not  the  same  as
> > installing  the  testing  glibc.  Nothing  on  the
> > system  changes.  System   glibc  stays  2.33.  No
> > upgradepkg of  a core  package, no  ld.so.conf, no
> > ldconfig.
> >
> > What the script does:
> >
> > - unpacks the snap into /opt/Signal/signal-desktop
> > - unpacks  aaa_glibc-solibs-2.42  into  the  same
> >   prefix, as a build source like any tarball
> > - patchelf on the Electron binary so its PT_INTERP
> >   and DT_RPATH point there
>
>         I don't see how this differs in a meaningful
>   way from the existing solution that was refused by
>   the SBo admins.  The only minor difference is that
>   you're extracting Signal from  a snap instead of a
>   .deb archive.  The testing glibc is installed into
>   /opt, and Signal binaries  are patched to point to
>   that glibc instead of  the system one.  If there's
>   some  other important  difference here,  please do
>   explain it a bit more.
>
> Best Regards,
> Lumin Etherlight
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20260813/4827bbc6/attachment.htm>