[Slackbuilds-users] [RFC] a binary repack SlackBuild template.

fsLeg fsleg at t-rg.ws
Tue Mar 4 07:42:11 UTC 2025


Interesting proposition. It definitely raises a few questions.

First, what about repackaging software from Debian-like packages? That's done a lot, and details vary from your SlackBuild, like, binaries usually go to /usr instead of /opt.

Second, speaking of /opt. I put pre-built things in /usr if it's the upstream practice, which it usually is. However, in my recently adopted popcorntime SlackBuild the upstream practice is to put the binaries in /opt, even if built manually or packaged, although I've seen someone on AUR putting those binaries into /usr/share instead. Should we follow the upstream? Should we formulate our own best practices? Basically, where do we put binaries and when? 

Third, does a repackaged package actually need to be named *-bin? Even if the only available SlackBuild only repackages the pre-built binaries. If so, then I might need to rename a script or two.

Fourth, steps for repackaging pre-built binaries don't vary much from building from source, minus the building part. With some toolchains you have to move things around manually anyway, so it's not so much about a template as guidelines where to put things.

What I think is needed is not just a template but a sort of an accompanying README about how to build packages that use different toolchains. Or just thoroughly document each step inside a SlackBuild, explaining why something is done a certain way, what to do and what to keep in mind if something doesn't apply to a particular piece of software.

On March 4, 2025 09:29:30 GMT+03:00, Lockywolf <for_slackbuilds-users_mlist_2023-04-21 at lockywolf.net> wrote:
>Dear SlackBuilds community,
>
>Increasingly, we have to write more and more binary repacks,
>as software is becoming harder and harder to build on the premises.
>
>While this is an unfortunate development, and the community members
>are encouraged to build software from the original sources to ensure
>transparency and flexibility, sometimes building a package as a
>repack is an unnecessary evil.
>
>This message has (attached) a proposed binary-repacking SlackBuild,
>which I would like to propose for an inclusion into the templates
>repository.
>
>Please comment and suggest how this template can be improved.
>


More information about the SlackBuilds-users mailing list