<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 15, 2024, 6:16 PM Lumin Etherlight via SlackBuilds-users <<a href="mailto:slackbuilds-users@slackbuilds.org">slackbuilds-users@slackbuilds.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hello, fellow slackbuilders,<br>
<br>
I'm working on an update for busybox; hasn't been updated for<br>
a while, and is behind many versions. Working on it, I found that<br>
the previous maintainer apparently included a custom build config<br>
with some substantial modifications. I'm planning on reverting the<br>
configs to be as close as possible to the default shipped by busybox,<br>
with few minor modifications, like buildings statically, and without<br>
symlinks that replace normal path utilities. I may later include an<br>
option to build dynamically, or a mechanism to load a custom .config<br>
file before building, but I'm afraid it would result in a huge number<br>
of edge cases during the installation process.<br>
<br>
Any thoughts on the following points:<br>
<br>
1. Is reverting to the default configs dangerous? It may break<br>
people's workflows, but the busybox package update already<br>
includes a large number of upstream changes anyway.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">There's always a chance a change or updated version will break somebody's workflow (<a href="https://xkcd.com/1172/">https://xkcd.com/1172/</a>). This is the reason Pat rarely upgrades packages on a stable release if there isn't a vulnerability or serious bug that needs to be addressed</div><div dir="auto"><br></div><div dir="auto">However, SBo, as a whole, is not under that restraint. As the package maintainer, you're free to update as little or frequently as you like. I generally try to keep my packages up-to-date, but others choose to update only when problems are found. Both are correct options.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 2. Is building statically by default and providing an option to<br>
build dynamically a reasonable approach? The default builds<br>
dynamically, but current SlackBuild builds statically.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">Based on SBo's templates, they prefer building packages with shared (dynamic) libraries. However, those templates are templates, so maintainers are free to use our disregard them.</div><div dir="auto"><br></div><div dir="auto">That being said, unless you have a good reason to disregard the templates, it's generally best practice to use them (which would mean shared by default).</div><div dir="auto"><br></div><div dir="auto">Personally, unless you know why the previous maintainer chose static, if might be worth making the default shared, and, if you desire (since you're the maintainer), you can make an option to make a static version.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 3. Should the SlackBuild allow loading custom build configs?<br>
Or should we assume that if a user wants to build their own<br>
custom version they will know what to do? Currently we ship a<br>
build config file, and even if we want to stay closer to default<br>
we most likely will still need to ship the build config file,<br>
as generating it from upstream package is an interactive menu<br>
process.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">Like my previous responses alluded to, you're the maintainer and as the maintainer, you get to make these decisions. </div><div dir="auto"><br></div><div dir="auto">It's generally a good idea to plan for the masses and possibly make exceptions for the few. Personally, I like making my SlackBuilds configurable, so I will add autodetect for optional dependencies and offer flags/variables users can pass to change the defaults. But that does add extra complexity that I'm willing to deal with, and this is with the very real possibility that users may not even choose to use my various options I've added. </div><div dir="auto"><br></div><div dir="auto">Ultimately, you're now the maintainer, which means you make the decisions that everyone else on SBo would need to deal with when using your script. Sometimes it's better to decide for the user (maybe a program has an optional dependency, but most users would expect the functionality that dependency offers, so maybe it's best to include it on the REQUIRES line in the .info) and sometimes it's good to give them a choice. </div><div dir="auto"><br></div><div dir="auto">I feel like my Kodi SlackBuild does a decent job of flags, autodetect, expected defaults. </div><div dir="auto"><br></div><div dir="auto">Just don't forget to document optional things in the README. </div><div dir="auto"><br></div><div dir="auto">Jeremy </div></div>