[Slackbuilds-users] [RFC] a binary repack SlackBuild template.
B. Watson
urchlay at slackware.uk
Sun Mar 23 20:46:30 UTC 2025
On Sun, 23 Mar 2025, Lumin Etherlight via SlackBuilds-users wrote:
> Back to the original topic of the thread's
> OP; whether we should have a SlackBuild template
> for binary repacks. I vote no. For two reasons:
>
> First, what repacks? A repack from .deb?
> from .rpm? from some .tar.gz built for Ubuntu?
> Some statically linked loose Golang binaries?
> There's no end to what a binary repack means.
Ideally, a template for binary repacks would have commented-out
example code for all of the above.
> Second, I don't think we should encourage
> binary repacks. They should be, in my opinion, a
> last-resort, when the software is very resource
> intensive to build, or only exists in binary form.
That, I can agree with.
> I already see too many packages existing as binary
> repacks only, too often just because it is easier
> than building them from source. I don't think I
> like that, I view it as a degradation of SBo's
> packaging quality.
I've been guilty of "easier than building from source" at least once:
I submitted a kitty-bin, before anyone had done a kitty from-source
build. I mostly did this for myself, because I wanted to try out
kitty, and submitted it to SBo in case someone else might find a use
for it.
It's gone now. Partly because there's no need for it, since there's a
proper from-source build, and partly because upstream's binaries need
newer libs (including glibc) than Slackware 15.0 has. Well, that,
and I really didn't like kitty once I'd tried it (I'll stick with
rxvt-unicode, thanks).
I guess the point of telling you that is, I named the build with -bin
specifically so someone else could use the proper name without -bin.
To me, that seems like a good idea, for stuff that can be built from
source but also provides binaries.
More information about the SlackBuilds-users
mailing list