android-tools from SBo claims to be downloading stuff from the Interhet while running
 

AFAIK, this goes against the SBo policy, isn't it?

I'm skimming through the SlackBuild http://slackbuilds.org/slackbuilds/1...ols.SlackBuild and I don't see any explicit downloading, so presumably it is not performed by the SlackBuild itself, but happens deeper, being done by something that the SlackBuild invokes, like cmake or ninja?

As an end user who needs android-tools as dependency (I need adb), yet isn't aiming to dive straight into the deepest details of installing Android toolchains in Linux, I'd still like to know a bit more about which part of the SlackBuild is downloading, what's being downloaded and what are the tradeoffs. Unfortunately, the short warning in the README is unsatisfactory, it feels not enough for an ELI5.

Could anybody with more knowledge about this explain it please? I thought it's better to ask here rather than bug just the buildscript maintainer with this question, hopefully this is the right place to ask and it's not offtopic.

Slackbuilds, at least those on Slackbuilds.org, list essentials. A user isn't required to download all but checksums are valuable so avoid at your own risk. That said one can get by just by downloading the slackbuild first wherever you prefer, unpacking it, and then downloading the source file(s) to the directory created while unpacking. The source need not be unpacked. Then, as root, run the foo.Slackbuild script either by preceding the command with "sh" or making the script executable.

Once it completes compiling, by default the created package will be "/tmp/foo.txz". I like to install it with "upgradepkg --install-new /tmp/foo/txz". After that final step you can use "man" to determine any appropriate syntax options or just try to run the executable(s) and feel your way around.

@enorbet I am familiar with how to use SlackBuilds, particularly SBo branded SlackBuilds. My question is about a particular SlackBuild - the android-tools one - which claims to be downloading stuff during its execution, which is not common at all. I am trying to figure out what exactly does it download, where exactly is it happening and why couldn't it be avoided.

Could it be to do with this? https://github.com/nmeum/android-tools/issues/47 or something else similar withing the android-tools build.

There is a warning about it on the SlackBuild page:
https://slackbuilds.org/repository/1...android-tools/

Warning does not make it OK. One good reason why SBo does not endorse remote features of SlacBuilds:
Packaging is tested for 1 source archive and 1 SBo setup script with optional patches.
Meanwhile a remote resource is often changed, and whenever that happens one must test the SlackBuild again.
This is impossible to test, it could work today and break tommorrow, and nobody would have a faintest clue whether or not it ever worked.

IMO it (whatever it's downloading) should be scraped from git, and shipped as a patch, tested once per version change.

Applying the suggested workaround (adding "export GO111MODULE=off" to the SlackBuild before cmake) appears to work, even without internet or directories at /root/go or /root/.cache/go-build. I suppose this allows boringssl to use system go or something?

Agree 100%. What exactly is being downloaded? Any file names? Any clues whatsoever?

Why does it matter? It's some component that android-tools maintainer should package, and not leave it for user to download.
I'm no android-tools maintainer, my only complaint is that as soon as google changes the component the SBo package becomes unstable.
And from past experience, SBo has been well tested and stable. So this thing, whatever it is, undermines the packagers' efforts.
Further more, it makes google in charge of updating the component but not liable for any breakage, so maintainer will get the blame.

It may not, but if it does not matter - why the warning?

Does android-tools matter to you? Contact the maintainer, I can't answer your question.
It matters to OP, because I assume he wants it fixed regardless of SBo maintainer.

All I'm saying is that warnings such as this one do not belong on SBo, for many reasons.
If the warning also said the package's unstable, untested, and only partially maintained, that would be the truth.
But since it's very convenient to omit these things and just dodge any responsibility, you get to "decide for yourself" if it really does matter to you.

TBH I'd rather see it dropped from SBo than have it serve as a bad packaging example, before other packages start issuing "warnings".

Not at present. But I probably will use them whenever a "degoogled" OS (Lineage, or whatever) becomes available for my phone.

Thank you for the clarification and I am aware that some Slackbuilds attempt to stay up to date by downloading "the latest and greatest" but how is that an unknown? I use a Slackbuild for Wine-Staging that downloads and attempts to compile the latest sources as clearly defined in the slackbuild script. Many times I've had to alter edit version or what web address sources are sought because over many years those specifics change, OR the latest won't yet compile and I have to drop back to one that's newer than what I have but will still compile on that system.

Are you saying your slackbuild somehow hides where and what downloads are called for?

I am saying that the SlackBuild doesn't seem to explicitly download anything with wget, hence I asked here in forum. Some people pointed that this might be related to Golang. It's the detail that would've made me happy in that warning, that's all.

Tried it, out of curiosity, on my 15.0 VM, using android-tools.sqf. This is what ends up in /root: