[Slackbuilds-users] Rust program packaging woes

[fsLeg]

Hello.

I've been maintaining a few SlackBuilds for myself in a private repo for 
quite a while. And recently I started thinking about submitting them 
officially here. But before I do that, I want to clarify a few things 
about packaging Rust programs, since I have a SlackBuild for one.

1. What is the policy with crates? The guidelines say that SlackBuilds 
must be usable offline, which would imply that crates should be 
specified in .info file. And the majority of Rust programs on SBo do 
just that.

But there are a few packages, namely network/electrs, network/noip-duc 
and graphics/veles, which don't do that for some reason, and electrs 
doesn't even mention requiring internet access.

Then there are audio/yabridge and python/python3-maturin which just use 
pre-bundled vendor/ directory uploaded to some place. IIRC such behavior 
is normally frowned upon.

So is there a single standard for SlackBuilds of Rust programs? Or I can 
just use regular `cargo build` without bothering with vendoring of 
crates? I looked up a lot of information on that topic, and general 
consensus seems to be to stick to Cargo for everything, even vendoring, 
which would imply that fetching a tarball with vendor/ directory should 
be preferred.

2. What is the policy with additional scripts? I wrote a python script 
to vendor all crates. Can I use it? Do I bundle it alongside the 
SlackBuild to call when needed or do I embed it using here-document? 
There's nothing about including custom tools in a SlackBuild submission, 
which would mean it's allowed if necessary.

I know that basically all SlackBuilds for Rust programs use a sub-shell 
with some voodoo inside, and at first I did too when I just switched to 
offline building. But I thought that looked way too dirty and hacky, and 
I prefer to understand what is happening. I understood a general idea, 
in fact it's what helped me to write my own script, but not what was 
happening with all those excessive regexps. I also tried to rewrite that 
chunk of magic in Shell in a more readable way, and I succeeded, but 
that code was way too slow (~3m20s for a program with 454 crates vs ~13s 
using a Python script or that black magic snippet).

BTW, python/python3-maturin actually includes such a helper script, 
although it's not referenced anywhere and it requires another package to 
be installed first.

3. A more broad question. What is the purpose of including a program's 
SlackBuild into /usr/doc? Is it transparency about how a particular 
package was built as well as who's responsible for deciding how to build 
it? Or is it so users could rebuild a package themselves? But in this 
case some SlackBuilds aren't usable as there's no additional files that 
the SlackBuild might use, like patches or custom scripts, including 
helper scripts. Do I also need to put my helper script in /usr/doc?

The SlackBuild in question: 
https://github.com/fsLeg/SlackBuilds/tree/master/shadowsocks-rust

I also wrote a tool to help maintain SlackBuilds for Rust programs: 
https://gist.github.com/fsLeg/2f33cccbce9f3ae6af1a3f720f201cb0 It needs 
some more love, but it mostly works. With it you can get a list of 
crates' links, get a list of crates' links with their MD5 hashes, add 
those to DOWNLOAD and MD5SUM variables of .info file respectively and 
finally vendor pre-downloaded crates to test the building process.