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

[Ιωάννης]

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.

thanks

Στις Τρί 4 Μαρ 2025 στις 9:42 π.μ., ο/η fsLeg <fsleg at t-rg.ws> έγραψε:

> 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.
> >
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20250304/fc0f5189/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: repack-template.SlackBuild
Type: application/octet-stream
Size: 9831 bytes
Desc: not available
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20250304/fc0f5189/attachment-0001.obj>