Help with Alpine build/packaging #52279
Comments
|
Does this command curl -fsSL https://install.julialang.org | shwork on Alpine? I would recommend adding juliaup (the Julia version multiplexer) as an Alpine package under the user-facing name "Julia". This is how it's done on Windows. Historically, distribution-packaged Julia builds have been buggy and out of date, and issues due to unofficial binaries tend not to receive as much community support. By giving users access to juliaup instead of Julia itself, users can manage their version of Julia themselves (including access to all historical versions since 1.0 and opt-in access to prereleases) without waiting for the distro-packaged version to be updated. |
|
Thanks for the quick response @LilithHafner! The command you provided fails immediately on Alpine with:
I was looking at how the |
|
It seems to me that toybox, the BusyBox replacement, has I realize it's not the default (why not?), I'm not sure if you can switch or have both available. It's the default here: I had not heard of that, you might first try it there, I'm not sure, it seems Alpine-based or at least similar. |
|
I could definitely be overlooking something, but on my system juliaup's julia installs are about half the size of built from source installs: @davidanthoff suggested a fix for the issue you linked—I imagine that making the PR he recommended would be a good way to avoid the |
|
So, I'm strongly in favor of packaging Juliaup as "julia", as @LilithHafner suggests. That is where we are generally going, i.e. the whole version multiplexing story of Juliaup is soon going to be considered a "default" part of Julia. Maybe the right approach to do this is actually add build recipe for Juliaup to Apline? I.e. don't try the curl download thing, but instead just clone https://github.com/julialang/juliaup, and then build using Rust? |
|
Thanks @LilithHafner and @davidanthoff I'm open to pursuing the |
|
@LilithHafner it looks like your size comparison above is using the default Makefile, but the APKBUILD I shared above uses a custom Makefile like this: Do you think this could be affecting the size of the build, or why is the juliaup-installed version so much smaller? Can anyone point me to the steps used to create the pre-built binaries that juliaup installs? Could you maybe try and run your build again using external dependencies and see what size the resulting binary comes out as? |
Looks like folks to the same with rust? https://pkgs.alpinelinux.org/package/edge/community/x86_64/rustup
Note that we decidedly warn against this and do not provide support for this configuration. |
|
With that makefile I got this |
|
To add some explanation for the opposition to
If you upstream all the Julia-specific patches into LLVM and there is some way of specifying a specific LLVM version dependency, then I imagine this could work. Though that would be a lot of work and there may be other significant obstacles I'm not thinking of atm. |
|
@vchuravy That is the @LilithHafner Thanks, I saw that a custom LLVM is necessary and tested (but didn't push) an APKBUILD that downloads and uses https://github.com/JuliaLang/llvm-project . I also saw the following note at https://docs.julialang.org/en/v1/devdocs/build/build/#LLVM
Could you provide more detail on these caveats? It looks like this passage was written almost 6 years ago when LLVM 5 was the current version, has the situation changed since with e.g. LLVM 17? There is some interesting discussion around this where devs are discussing how package maintainers should handle these deps in the PR that added the text above over at #25912 |
If you use
The situation is fundamentally unchanged. Julia versions and LLVM versions are tightly coupled, and while we have upstreamed many of our patches we also find ever more that we need to temporarily carry. If someone encounters an issue we will ask where they obtained Julia from and ask them to reproduce the issue with an official build. This prevents duplicated work from having to debug the same issue multiple times. Archlinux had to include a disclaimer https://wiki.archlinux.org/title/Julia because we kept running into this situation multiple times. As a note a second dependency where this holds true is libuv. |
|
Thanks, I'm now fully convinced packaging My issue is now that |
|
https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/56206
|
Personally, I would prefer if distros all packaged |
|
Very much agree with @StefanKarpinski! On Windows that is how things are already, "Julia" in the Windows Store is really Juliaup. |
|
This appears to be more of a discourse discussion than an issue currently |
I'm trying to learn Alpine packaging and picked Julia after seeing the package request here. Julia 0.6.2 was last packaged for Alpine around 5 years ago, so I have this old APKBUILD file to work from: https://gitlab.alpinelinux.org/alpine/aports/-/tree/v3.18.4/unmaintained/julia
My approach is to start more or less from scratch, bump all versions and start trying to run the build, applying fixes from the old APKBUILD if they still seem relevant. Partial work is here: https://gitlab.alpinelinux.org/strophy/aports/-/blob/testing/julia/testing/julia/APKBUILD
I'm running into the following issue at the moment:
Can someone help me understand the difference between
gfortranandlibgfortranwhich already exist as Alpine packages with v13.2.1, andlibgfortran5,libgfortran4andlibgfortran3available from https://github.com/JuliaBinaryWrappers/CompilerSupportLibraries_jll.jl/releases ? I don't see an option likeUSE_SYSTEM_GFORTRANwhich exists for other packages where we should try and use the system dependency. Why does it still attempt this download, even if the package is already available as a local system dependency?For
libuv, why is the latest version at https://github.com/JuliaLang/libuv 1.44.2 but https://github.com/JuliaBinaryWrappers/LibUV_jll.jl offers 2.0.1?The previous maintainer of this package seemed very determined not to allow
jldownloadto download anything during the build process, is this still a practical approach to packaging Julia?The text was updated successfully, but these errors were encountered: