fix musl versiondb links and generator

[strophy]

Resolves #762

While attempting to package Juliaup for Alpine Linux (musl libc) I experienced failures during cargo test due to juliaup incorrectly downloading glibc binaries to a musl libc system.

     Running tests/channel_selection.rs (target/debug/deps/channel_selection-ec83ce41afe3622d)
running 1 test
test channel_selection ... FAILED
failures:
---- channel_selection stdout ----
thread 'channel_selection' panicked at 'Unexpected failure.
code=1
stderr=``````
Error: The Julia launcher failed to start Julia.
Caused by:
    No such file or directory (os error 2)
\```
\```
command=`JULIAUP_DEPOT_PATH="/tmp/.tmphOgVTW" JULIA_DEPOT_PATH="/tmp/.tmphOgVTW" "/builds/strophy/aports/testing/juliaup/src/juliaup-1.12.5/target/debug/julialauncher" "-e" "print(VERSION)"`
code=1
stdout=""
stderr=```
Error: The Julia launcher failed to start Julia.
Caused by:
    No such file or directory (os error 2)
\```
', /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/core/src/ops/function.rs:250:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
    channel_selection
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 39.29s
error: test failed, to rerun pass `--test channel_selection`
>>> ERROR: juliaup: check failed

No such file or directory occurs while trying to execute the binary on a system where /lib64/ld-linux-x86-64.so.2 is not present. This PR adjusts the download links in the versiondb directory, and naively attempts to update what I think is the generator script for these files. I don't see any tests for this generator, and I'm not sure how to actually build and execute Julia code. I was however able to successfully build a package based on this branch, so cargo tests work on musl now.

[davidanthoff]

I think that looks right to me, but I need to double check that this doesn't break things on systems with the GNU libc. I have a vague memory that we statically link musl in Juliaup itself even on GNU systems so that we don't rely on the system libc, and we just need to double check that this PR here doesn't lead to a situation where then on GNU systems it also downloads the musl version of Julia.

Also, just for my own sanity, if @staticfloat could take a quit think about this here as well that would be great. In general, the musl builds of Julia are just as official as everything else, right?

[strophy]

Hi @davidanthoff @staticfloat happy new year! Do you guys expect to find time to review this soon, should I keep up rebasing as the main branch changes? Alpine have asked me to either complete this work or close the PR on their repo, but I am blocked until this bugfix PR is merged and a new version of juliaup is released.

[staticfloat]

In general, the musl builds of Julia are just as official as everything else, right?

Yes, but note that we only build for x86_64-linux-musl, we don't build i686, aarch64 or armv7l musl.

[strophy]

Thanks for the response! Does that mean we should delete versiondb/versiondb-aarch64-unknown-linux-musl.json and versiondb/versiondb-i686-unknown-linux-musl.json? Why are these files generated if there are no corresponding builds available to download?

I understand 32-bit arch isn't supported due to dependencies and this is really a separate issue for the julia repo, but would you consider adding aarch64 musl builds?

[staticfloat]

I understand 32-bit arch isn't supported due to dependencies and this is really a separate issue for the julia repo, but would you consider adding aarch64 musl builds?

x86_64 musl already has lots of problems due to lack of developers that are experienced with the platform and able to track down bugs, I don't think it's viable for us to find people able to debug aarch64+musl issues as well. The current x86_64-linux-musl build constantly segfaults due to what we believe is a bug in one of our dependencies on musl, but despite our best attempts at solving it, it remains, and will likely prevent us from releasing even x86_64-linux-musl builds for future Julia versions until it is solved. If you care about Julia on musl, any developer expertise you can send our way to track down these issues would be most appreciated.

[davidanthoff]

Alright, I looked into this now, and this is more complicated, unfortunately.

The current logic here is as follows: The target platform of the Juliaup binaries determines which version db json is going to be used here. So, for e.g. the x64 Juliaup build that uses musl, versiondb-x86_64-unknown-linux-musl.json is going to be used. Here is the twist: the default shell download install method always gives users a musl build of Juliaup because we statically link musl into that build so that we have as little deps as possible. But of course we want those Juliaup binaries to download the regular gnu versions of Julia.

So in general on Linux the situation is that we will be using musl build version of Juliaup itself always, so we can't use the fact that Juliaup is built using musl as the decision criterion for whether we want musl or gnu versions of Julia to be the default.

I think what we probably need to do is this: add another cargo feature named juliamusldefault or something like that, so that one can compile a version of Juliaup that uses a new set of version db json files that point to the musl versions of Julia as the default.

Another question on that topic in general: would it make sense that Linux users could access musl/gnu versions via more platform specifiers always? Say juliaup add release~x64-musl and ``juliaup add release~x64-gnu` or something like that?

I think another question is whether we should support anything other than tier 1 platforms? I think probably yes, but probably also worth discussing.