<div dir="ltr"><div>Personally I use some scripts for local builds that support various compress types. I tried edit repack-template.SlackBuild to add some options maybe you find something useful  for the final repack-template.SlackBuild.<br><br></div>thanks<br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Στις Τρί 4 Μαρ 2025 στις 9:42 π.μ., ο/η fsLeg <<a href="mailto:fsleg@t-rg.ws">fsleg@t-rg.ws</a>> έγραψε:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Interesting proposition. It definitely raises a few questions.<br>
<br>
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.<br>
<br>
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? <br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
On March 4, 2025 09:29:30 GMT+03:00, Lockywolf <<a href="mailto:for_slackbuilds-users_mlist_2023-04-21@lockywolf.net" target="_blank">for_slackbuilds-users_mlist_2023-04-21@lockywolf.net</a>> wrote:<br>
>Dear SlackBuilds community,<br>
><br>
>Increasingly, we have to write more and more binary repacks,<br>
>as software is becoming harder and harder to build on the premises.<br>
><br>
>While this is an unfortunate development, and the community members<br>
>are encouraged to build software from the original sources to ensure<br>
>transparency and flexibility, sometimes building a package as a<br>
>repack is an unnecessary evil.<br>
><br>
>This message has (attached) a proposed binary-repacking SlackBuild,<br>
>which I would like to propose for an inclusion into the templates<br>
>repository.<br>
><br>
>Please comment and suggest how this template can be improved.<br>
><br>
_______________________________________________<br>
SlackBuilds-users mailing list<br>
<a href="mailto:SlackBuilds-users@slackbuilds.org" target="_blank">SlackBuilds-users@slackbuilds.org</a><br>
<a href="https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="https://lists.slackbuilds.org/pipermail/slackbuilds-users/" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="https://slackbuilds.org/faq/" rel="noreferrer" target="_blank">https://slackbuilds.org/faq/</a><br>
<br>
</blockquote></div>