[Slackbuilds-users] Updates - 20230128.1

Mohammad Matini mohammad.matini at outlook.com
Mon Jan 30 23:27:05 UTC 2023


>>> Bingo.  Multiple packages that depend on java pick a version to put
>>> in REQUIRES but then the README notes that you can optionally use a
>>> different version.  If the SlackBuild tries to source the version in
>>> REQUIRES it will fail hard.

>> Java is special case (there are too many of them).
>> A single "source /path/to/file" is not much complexity.

Incidentally, two days ago I was hunting down a bug with Docker Swarm on
Slackware, which we use in production at one company I do consulting for,
and so I had multiple golang versions installed on the dev machine, and
rebuilt and tested half a dozen SlackBuilds multiple times under the
different versions of golang, to compare the behavior between them.  I did
that by simply setting my $PATH and $GOROOT to whichever installation I
needed at the time.  An automatic sourcing of the profile.d script would
have overridden my choice without me knowing.  I will have to notice this,
figure out why it is happening, then edit all the SlackBuilds I'm testing to
stop sourcing it.

My case is likely not a widespread one, but it would surprise me if my $PATH
and $GOROOT were being overridden automatically by build scripts.

One man's useful automation is another's inflexibility, and surprise :]

I surely got hit with build issues for forgetting to source the golang
profile.d script once or thrice before, and wasted a bit of time on it first
time it happened, but I know it when I see it now.  A better error would
have been nice the first time of course.  If we must provide a better error,
then I would suggest the script somehow check whether it is using Google's
Go, or GCC's Go, and warn or abort the build upon detecting the later.  This
would provide better error information, without doing unexpected overrides.

Aborting may again be too heavy handed; a user who wishes to test a bunch of
packages with a newer version of GCC Go, to see whether they work with it
now, will also have to edit all the SlackBuilds to disable the assertion.

So a warning may be best, I guess.  Maybe something like:

go version | grep -qv gccgo || cat <<-EOF
!!!===============!!!=================!!!=================!!!==============!!!
   WARNING: You're using GCC GO, this SlackBuild requires Google's Go instead
   (development/google-go-lang).  Remember to source /etc/profile.d/go.sh or
   /etc/profile.d/go.csh after installing google-go-lang to actually use it.
!!!===============!!!=================!!!=================!!!==============!!!
EOF


>> Also, users don't use slackrepo, they use sbopkg and sbotools.

On a side note: I would caution against such reductionist statements, in
either direction; who are the "users"?  We have dozens of machines running
Slackware, for years, for multiple clients, and we don't use any of those;
we use in-house automation scripts, or build manually when debugging or
doing experiments.  While one of those tools may truly be used by most
users; changing things to fit that tool while excluding others from
flexibility and control would compound, with time, to end up with nothing
more than an Ubuntu-like system; tailored to fit and serve the perfectly
average user, a user that doesn't even actually exist.


Aaanyway, thank you all for
your work and care :)
Mohammad Matini


More information about the SlackBuilds-users mailing list