[Slackbuilds-users] Slackbuild with Two Executables

Brandon Pribula b.pribs11 at gmail.com
Thu Mar 24 02:35:54 UTC 2022


On Wed, Mar 23, 2022, 1:16 PM B. Watson, <urchlay at slackware.uk> wrote:

>
>
> On Wed, 23 Mar 2022, Brandon Pribula wrote:
>
> > Well for the environment variable approach I wanted to give the option of
> > installing both, so in that case the executables would have to have
> > different names. So in terms of the script I thought it would make sense
> to
> > just have distinct names for the executables no matter which option they
> > chose.
>
> Yes, but... if you're going to have 2 separate executables,
> with different names. Why bother with the environment variable
> at all? Just include both executables (e.g. /usr/bin/appname and
> /usr/bin/appname-posix) in your package, and mention in README that
> there are two, and give both their names. Users who prefer the -posix
> version can just type "appname-posix" to use it, and users who don't
> care can just type "appname"...
>
> It'd be different if they were mutually exclusive, a compiled program
> that either has or does not have some option built in. Or if your
> programs were huge and took up a lot of disk space, so a user might
> care about not installing the one he doesn't need.
>
> In the absence of such concerns, go with simplicity: don't force a
> user to make a choice if it's trivial to avoid it. If I were a new
> user of your app that you're packaging, I'd have no idea whether
> I wanted the regular or -posix version, so I'd either go with the
> default (most people do), or have to spend time & effort researching
> the alternative.
>
> Slackware for instance includes two emacs executables (emacs-with-X11
> and emacs-no-X11), and two strings commands (strings-BSD and
> strings-GNU)... although those are more complex examples, using
> symlinks. You won't need symlinks, it doesn't sound like.
>

That's true. I did think I could make installing both the default. If the
user wants to install only one version they could specify which with an
environment  variable otherwise no environment variable is used. This does
feel overengineered considering the small size of the executables, etc. The
only other justification I can think of to give the user a choice would be
minimalism. But this kind of minimalism isn't part of the Slackware
philosophy.

Thanks for talking it through with me. I'll just have the script install
both. KISS.

>
> > I didn't realize there were that many slackbuilds. That's impressive!
>
> They sorta grew beyond expectations, but that just means we're doing
> something right.
>

I did notice looking for software that isn't packaged for Slackware is
quite difficult. Most of the time when I go looking it's available on SBo.

There's quite an increase of activity on the Slackware sub-forum since the
release of 15.0. Hopefully it will continue to attract new users and bring
back old users leading to more SBo maintainers.

> _______________________________________________
> 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/20220323/89edb767/attachment-0001.htm>


More information about the SlackBuilds-users mailing list