Distributions

Posted Feb 3, 2025 14:45 UTC (Mon) by leephillips (subscriber, #100450)
In reply to: Distributions by stephanlachnit
Parent article: New horizons for Julia

Julia is available through the package managers of all major Linux distributions, but, as warned on the official Julia download page, you shouldn’t use these packages. Such packages are typically put together by people involved with the distributions, not the developers of the packaged software. In the case of Julia, some distributions package broken Julia installations, some are simply out of date, and some are fine. I use Debian; most packages for actively developed, end-user software are very out of date, and Julia is no exception. I use the Debian package manager for utilities such as Bash and for shared libraries, etc. For mutt, zsh, Google Chrome, Postgres, and almost everything else that I interact with directly, the package manager is useless and I download the software from the developers’ sites, either in binary or source form. This is normal.

Fedora, for another example, happens to package an up-to-date Julia.

If the Julia site instructed people to use their distributions’ package managers the Julia devs and community would spend an inordinate amount of time fielding bug reports and questions that have nothing to do with Julia but arise from the broken nature of these packages. They could devote themselves to working with each distribution to help them package a timely, non-broken Julia for each new release, but I, personally, would much rather that the massive amount of developer time that this would consume be dedicated instead to developing Julia.

See https://github.com/JuliaLang/julia/issues/32639#issuecomm... for further detailed explanation of why depending on distribution packaging for Julia would present a host of problems.

Distributions

Posted Feb 3, 2025 15:17 UTC (Mon) by intelfx (subscriber, #130118) [Link] (9 responses)

> but, as warned on the official Julia download page, you shouldn’t use these packages

Any free software project that posts this kind of "warnings" earns my immediate distrust, and it would take *a lot* to offset it.

> Such packages are typically put together by people involved with the distributions, not the developers of the packaged software.

And that's how it should be.

Distributions

Posted Feb 3, 2025 15:41 UTC (Mon) by Wol (subscriber, #4433) [Link] (1 responses)

> > Such packages are typically put together by people involved with the distributions, not the developers of the packaged software.

> And that's how it should be.

And that's how it SHOULDN'T be. Would you want your car serviced at the local garage by an unsupervised apprentice?

IF (unlikely) I ever get any software of mine into a mainstream distro, I would consider it very important that I provide up-to-date build options for any distributions of importance to me. Probably Gentoo, SUSE, Slackware. I would expect any collaborators to do the same for distributions of importance to them.

Expecting people who aren't involved with the software (*especially* if it's under active and rapid development) to package it is just asking for something to go wrong.

Cheers,
Wol

Distributions

Posted Feb 3, 2025 17:26 UTC (Mon) by jond (subscriber, #37669) [Link]

And that's how it SHOULDN'T be. Would you want your car serviced at the local garage by an unsupervised apprentice?

I don’t like this analogy because it presumes there is only one field of expertise that matters. I fully accept that the developers of a program are the experts in that domain; but packaging itself (and distribution specific facets) are another relevant domain entirely, which upstream developers rarely are expert in. I agree there’s a problem here. But the way you’ve presented it I think misses important nuances.

Distributions

Posted Feb 3, 2025 16:00 UTC (Mon) by leephillips (subscriber, #100450) [Link] (6 responses)

“Any free software project that posts this kind of "warnings" earns my immediate distrust”

But this sort of thing is extremely common, because packages from distributions are so often useless.

Just looking at some of the free software I use every day:

The Mutt (the email client I use) official wiki instructs users to install by downloading the source from mutt.org and compiling.

Dwm (the window manager I use) tells users to download source and install, pointing out that it would be “pointless” to distribute binary packages.

Pandoc recommends downloading from pandoc.org to get a recent version.

LaTeX: they mention that distribution packages are typically out of date and direct users to download from the project.

Distributions

Posted Feb 3, 2025 16:22 UTC (Mon) by Wol (subscriber, #4433) [Link]

Okay, this story is many years old (I don't know how long I've been using gentoo, but it's a LOT of years), the reason I switched to gentoo was because I was running the latest SUSE, the latest distro version of lilypond, and for whatever reason I needed a much newer version of lilypond.

Cheers,
Wol

Distributions

Posted Feb 3, 2025 17:29 UTC (Mon) by jond (subscriber, #37669) [Link] (2 responses)

But this sort of thing is extremely common, because packages from distributions are so often useless.

This framing is disingenuous. The mutt package, to pick your example, is obviously not useless; it’s widely used by many people. I used it myself for at least 20 years. I’m sure that you’re right, the upstream maintainer would prefer I used a more recent release, but that’s a different matter from the older version being useless.

Distributions

Posted Feb 3, 2025 17:43 UTC (Mon) by leephillips (subscriber, #100450) [Link] (1 responses)

I admit that an out-of-date package might not be useless, and in fact I use some of them where it doesn’t matter to me whether I have a recent release. But my statement is still true, that “packages from distributions are so often useless”.

Distributions

Posted Feb 3, 2025 18:14 UTC (Mon) by jzb (editor, #7867) [Link]

I'm not sure useless is a, well, useful term here. Perhaps what you mean to say is that packages from the distribution are older than you or other users would prefer, or that they may be altered in some way that is less optimal for some or many users—for example, those who depend on / want a vanilla upstream version/experience.

If that is what's meant, I don't think that's controversial at all. I am quite happy to get the bulk of my software from my distribution of choice, but I do compile certain things (e.g., aerc) from source because I want the very, very latest as it's still pretty new and fixes and features land regularly. OTOH, I am not going to bother to compile VLC, Foliate, Pandoc, or ffmpeg myself unless there's a really good reason.

Distributions

Posted Feb 3, 2025 17:35 UTC (Mon) by ballombe (subscriber, #9523) [Link]

This is different.
They tell you how to get the latest version, they do not tell you that you should not use distro version.
(it should be noted that lot of linux users are running very old LTS release like Ubuntu 18.04 which can be annoying to upstream, but it is not the distributions fault).

Mutt
"Figure out if you have a mutt installed already by entering "mutt -v" at the prompt. If you have none yet, or the displayed configuration doesn't suit your needs, grab the source from http://www.mutt.org/download.html and "do it yourself": install mutt."

DWN
"Because dwm is customized through editing its source code, it's pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. There are some distributions that provide binary packages though."

PANDOC
"Check whether the pandoc version in your package manager is not outdated. Pandoc is in the Debian, Ubuntu, Slackware, Arch, Fedora, NixOS, openSUSE, gentoo and Void repositories."

LaTex
"Check your Linux distributions software source for a TeX distribution including LaTeX. You can also install the current TeX Live distribution directly---in fact this may be advisable as many Linux distributions only contain older versions of TeX Live, see Linux TeX Live package status for details."

Distributions

Posted Feb 13, 2025 8:55 UTC (Thu) by anton (subscriber, #25547) [Link]

I use mutt, pandoc, and latex from Debian oldstable, and I find them useful. Of course they do not offer newer features, but that does not make the old versions useless. If you think that the current upstream version of mutt, pandoc, and latex are useful, why would they become useless in the future?

OTOH, the Debian package maims gforth by deleting the manual (they do not put it into non-free or something, they just do not distribute it at all). This makes Debian's Gforth distribution mostly useless without internet access; ok, not completely useless: It still can be used for building upstream Gforth from git (but there are frequent snapshot tarballs of upstream Gforth, so that benefit is small).

Distributions

Posted Feb 3, 2025 21:39 UTC (Mon) by wjb (subscriber, #71810) [Link] (3 responses)

I've been trying Julia recently and thought I'd try building it from scratch, then started to wonder how that worked and fell in a rabbit hole.

It's got a hellish build, or if I'm being kind, "fragile". All done with make, the makefile's all follow a pattern (which is good I suppose), but they are hard to follow (yes I know that's my problem) and the header->object dependencies are detailed & explicit (which makes me think they're generated, there's no actual sign of that but I'd hate to think they're maintained manually). Also lots of bundled/patched/forked dependencies, which makes me uncomfortable because "why?".

Distributions

Posted Feb 3, 2025 23:40 UTC (Mon) by leephillips (subscriber, #100450) [Link] (2 responses)

You are brave. I’ve never tried compiling Julia from source.

An explanation for at least some of the patched dependencies (mentioned in the Github issue I linked in a previous comment) is the circumstance that the Julia project uses patched versions of several libraries, most notably LLVM itself, to which it has contributed many improvements and fixes.

Distributions

Posted Feb 4, 2025 18:29 UTC (Tue) by ballombe (subscriber, #9523) [Link] (1 responses)

So you neither use distribution binaries nor compile them from source ?
What are you advising to do then ?

Distributions

Posted Feb 4, 2025 19:01 UTC (Tue) by leephillips (subscriber, #100450) [Link]

To install Julia, go to https://julialang.org/, click on the big green Download button, and follow the instructions.

Distributions

Posted Feb 5, 2025 19:48 UTC (Wed) by stephanlachnit (subscriber, #151361) [Link]

I agree that for some software, package managers are not the best way to get it anymore. Like GUIs (use flatpak) Rust crates (use cargo) or even most Python packages (use pip).

But this is not true for the core languages. It would be horrible for user friendlyness if GCC or Python itself are not available in most distributions. It is already not ideal for Rust.

Sure, developers can and will use more upstream compiler / interpreter version, but if you get started or just want to compile / use software X, this should not be a requirement. This is where Julia fails.

I can even understand, that they complain about broke distro builds. But it is an entirely self-made problem: Julia's developer don't understand or don't want to understand how distros work, why their build system and bundling is horrible, and how that leads to broken builds. Almost every other relevant langauges manages to get the core language components in all major distros. Most even care about it. Except Julia.

Distributions

Posted Feb 6, 2025 10:59 UTC (Thu) by aragilar (subscriber, #122569) [Link]

It been out of Debian-based distros for a few years now.

Distributions

Posted Feb 27, 2025 18:13 UTC (Thu) by zimoun (guest, #136589) [Link]

Hum, I would like to mitigate a bit. :-)

First, I find surprising that on one hand, LWN covers Reproducible Builds and Supply Chain attack and on the other hand, kind of promote an anti-pattern as `juliaup`. Somehow, that's because downstream distribution and third-party are not able to fully audit that some supply chain attacks pop up here or here, IMHO.

Second, as one packager of Julia for Guix, the pin-pointed message #32639 does not appear fully accurate. The issue is not about their own Julia patched libraries -- in Guix, we include them as `llvm-julia` or `libuv-julia` etc. -- the real issue is that Julia upstream does not really care about downstream distribution. Somehow, Julia upstream (kind of) promotes: our binaries or nothing -- as you wrote :-) --; so see first point above. ;-)

That's said, Julia is a great programming language. And I always enjoy LWN's cover of Julia, very good job. Thank you!