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.
_______________________________________________
SlackBuilds-users mailing list
[email protected]
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/
