[Slackbuilds-users] Rust program packaging woes
fsLeg
fsleg at t-rg.ws
Sun Dec 22 09:25:19 UTC 2024
On 22.12.2024 02:55, fourtysixandtwo wrote:
> First of all, it
> is very slow checking all those hashes and when you do a lot of build
> testing, that is very annoying.
I found that it's actually not that slow and might be a code issue. Like
I said, my Shell script takes over three minutes while Python and
Lockywolf's (I found the author) magic snippet is done in seconds, and
that's to untar 454 crates and hash 26000+ files inside. If you're just
going to check crates' checksums it shouldn't take more than a second or
two to check the downloaded crates against their MD5. There's not that
many Rust packages on SBo for that to be an issue.
As I was writing that paragraph I slowly realized you were talking about
the building process, not just source checking. Yeah, that would add up
quickly. Although Shadowsocks-rust currently seems to be the program
with the largest amount of required crates, so it should be faster for
everything else.
> Second, if one does not use
> cargo-vendor-filterer to create the list it includes a lot of useless
> crates for windows or other architectures we don't support which
> increases the download size by quite a bit.
I've been trying to do that manually for, like, two weeks. It turned out
some crates have a hard dependency on Windows-specific crates, so Cargo
was refusing to build my package unless I vendored all crates specified
in Cargo.lock. Stupid, I know, but it is what it is. Maybe it's better
for other programs.
I also just tried cargo-vendor-filterer. Yeah, the number of crates in
my case stayed the same, 454.
> Note that I will eventually be creating a separate slackbuild for the
> cargo-mkvendored.sh script I include with cargo-vendor-filterer as the
> latter is included in -current.
I think a script like that should be included alongside the templates,
maybe inside a directory with some helper scripts, as it's mostly usable
for packagers and is not actually used in the building process. Also a
SlackBuild for a single script feels like an overkill.
More information about the SlackBuilds-users
mailing list