[Slackbuilds-users] Reverting system/busybox to Default Build Configurations

[Jeremy Hansen]

On Sun, Sep 15, 2024, 6:16 PM Lumin Etherlight via SlackBuilds-users <
slackbuilds-users at slackbuilds.org> wrote:

>
> Hello, fellow slackbuilders,
>
>         I'm working on an update for busybox; hasn't been updated for
>   a while, and is behind many versions.  Working on it, I found that
>   the previous maintainer apparently included a custom build config
>   with some substantial modifications.  I'm planning on reverting the
>   configs to be as close as possible to the default shipped by busybox,
>   with few minor modifications, like buildings statically, and without
>   symlinks that replace normal path utilities.  I may later include an
>   option to build dynamically, or a mechanism to load a custom .config
>   file before building, but I'm afraid it would result in a huge number
>   of edge cases during the installation process.
>
>   Any thoughts on the following points:
>
>      1. Is reverting to the default configs dangerous?  It may break
>         people's workflows, but the busybox package update already
>         includes a large number of upstream changes anyway.
>

There's always a chance a change or updated version will break somebody's
workflow (https://xkcd.com/1172/). 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

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.

     2. Is building statically by default and providing an option to
>         build dynamically a reasonable approach?  The default builds
>         dynamically, but current SlackBuild builds statically.


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.

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).

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.

     3. Should the SlackBuild allow loading custom build configs?
>         Or should we assume that if a user wants to build their own
>         custom version they will know what to do?  Currently we ship a
>         build config file, and even if we want to stay closer to default
>         we most likely will still need to ship the build config file,
>         as generating it from upstream package is an interactive menu
>         process.


Like my previous responses alluded to, you're the maintainer and as the
maintainer, you get to make these decisions.

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.

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.

I feel like my Kodi SlackBuild does a decent job of flags, autodetect,
expected defaults.

Just don't forget to document optional things in the README.

Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20240915/a278a668/attachment.htm>