[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