[Slackbuilds-users] Rust program packaging woes

[B. Watson]

On Sat, 21 Dec 2024, fsLeg wrote:

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

The ones that require 'net access during the build are "grandfathered
in". We're not accepting new builds that need network access.

If electrs doesn't mention it in the README, that's a bug. Thanks for
pointing it out.

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

Frowned upon by whom? I'm a SBo admin, and I don't frown on it. In
fact I do the same thing whenever I have to: host the source myself,
if there's some reason the original source URL(s) won't do.

The only build I ever maintained that uses rust was libopenraw, and
I used to use a self-hosted vendor/ tarball. In the later versions,
upstream now includes all the rust sources in their release tarballs,
so I don't have to do that any more.

TBH, I don't like dealing with .info files with hundreds of crates, so
I generally just don't package up anything written in rust. libopenraw
is a corner case: when I took over as maintainer, it was originally
pure C++. At some point, it got some Rust added to it (but still is
primarily C++).

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

A tarball of vendor/ is preferred because it's the simplest way to
do it, assuming you have a place to host it. If you don't, someone on
this mailing list will probably volunteer to host it for you, or maybe
give you write access to the sourceforge sbodirectlinks account (not
sure who's in charge of that).

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

Definitely allowed. A lot of existing scripts include helper scripts.
No need for a here-doc. Just include it as a separate file, and run
it from $CWD in the script. If at all possible (and it generally is),
please ship the script non-executable, mode 0644, and run it from
within the SlackBuild with e.g. "sh $CWD/helper.sh" or "python3
$CWD/helper.py" (whatever interpreter's needed).

You don't want to depend on execute permission in $CWD, because our
tarball-creation process might remove the +x bits.

Writing to $CWD, even just "chmod +x $CWD/script.py", is forbidden. A
few builds may break this rule, but it's still a rule.

I'm actually working on a "maintainer FAQ" that includes this kind of
information. It's one of those never-ending projects... your questions
will go in there.

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

So you've got a python script that works and is more readable,
maintainable than the shell script other builds use? Definitely
include it in your build, and possibly it'll end up being mentioned in
a (hypothetical so far) rust template.

> 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?

So far as I know, the SlackBuild is included for reference
purposes. There's no expectation of being able to run it, since any
other files (even the slack-desc) aren't present in /usr/doc.

Any helper scripts you write, you don't have to include in the
package. See games/mame, there's a mkgroovy.sh script that I run
when it's time to update mame, but it doesn't go in the installable
package.

> 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.
> _______________________________________________
> 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/
>
>