[Slackbuilds-users] Build Environment Reminder

[Willy Sudiarto Raharjo]

>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 :)

From my *personal perspective*, this approach is fine since it's
contained *only* for this spesific package, so we can keep using the
original GLIBC from Slackware 15.0.
It's like how alienBOB provide some of his package where all
modules/dependencies are linked statically into his single package
without linking to outside libraries.

the disadvantages of this approach is that the output package will be
slightly bigger in size


--
Willy Sudiarto Raharjo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 870 bytes
Desc: OpenPGP digital signature
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20260814/80a943ec/attachment.asc>