this post was submitted on 01 Oct 2024
62 points (88.8% liked)
Linux
48652 readers
1025 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Distro packages don't really matter much in my experience. You either use project-specific package management or install stuff with Homebrew or Nix package manager. Sometimes maybe even containers.
One problem with distro packages is that you can only install one version. And in practise a lot of software projects have outdated dependencies. Sometimes you have multiple projects with conflicting version dependencies.
Well, now you are hitting on my real recommendation which is to use Distrobox. Distrobox allows you to install multiple userlands that are all isolated from each other but all seem native on your system and give you full access to shared files and resources ( even the GUI desktop ).
It is very common to work on something not that just has outdated packages but that targets a specific distribution. If you are building something that will target an Alpine container in the cloud, it is handle to create an Alpine Distrobox to have all the same libraries. Similarly an app might target a specific version of Ubuntu. One of the products I worked on last year was based on Ubuntu 18.04. I could easily create an Ubuntu 18.04 Distrobox to work on that.
Distrobox also means I can prevent the build-up of cruft from all the little specialty tools and dependencies that projects require that I will not need long term. Remove the Distrobox and remove all the junk.
This is different than pure Docker to Podman though since Distrobox still gives you full access to your base system. You only have to install what you uniquely need in Distrobox. So i am not necessarily installing all my tools in Distrobox. Just the specialty ones.
Anyway, this is a more complicated answer and setup. In my view, the host environment still matters a lot and what I said above still stands.
Heh, Distrobox came to my mind when writing my comment. I haven't used it enough to recommend it yet though.
I recall there are some other development container projects, but can't remember the names right now.
Development containers are nice in theory. In practice, sometimes development environments are so complex that it might not be worth the trouble. But it's good to have options.
This isn't technically true for all distros—Gentoo has a mechanism that will allow multiple package versions to be installed in parallel. I have multiple distro-packaged Python and Lua interpreter versions on my system, for instance. But it does require some extra work by the packager, so it isn't done universally for all packages.
Are these made similarly to how Debian handles python2 and python3 for instance?
I'm not sure that anything short of a package manager that would compile everything from sources would be able to provide capability to pick and mix specific package versions.
I don't know how Debian's solution works, so I couldn't say for certain. Gentoo usually installs the different package versions to their own directories, and there are methods for selecting a "system python" (or lua, etc) which is the target of the
/usr/bin/pythonsymlink. Other versions have to be called with qualifiers (for instance,python3.10). Python libraries installed through the package manager may install to one or several versions depending on the content of a couple of environment variables, and applications that need python can request a specific version if they need to, or accept the system python if they don't care. (Note that python2 is no longer eligible to be the system python—you need at least one python3, although 2.7.18 remains in the package repository and can be installed as well if you really need it.)Of course, if you're not a programmer, you can leave the defaults for everything alone, and most of the time it should Just Work.
Sounds pretty close to Debian as far as I remember. In Debian those symlinks are called alternatives, and can be configured with update-alternatives. Not sure about the Python libraries though.