0

I'd like to install libuv on a Ubuntu WSL instance, and I specifically need version 1.45.0 or later.

My understanding (from this tutorial article) is that the command to find out what versions of a package are available to install is apt list | grep:

$ apt list | grep libuv

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.


libuv1-dev/jammy,now 1.43.0-1 amd64 [installed]
libuv1/jammy,now 1.43.0-1 amd64 [installed,automatic]
libuvc-dev/jammy 0.0.6-1.1 amd64
libuvc-doc/jammy 0.0.6-1.1 all
libuvc0/jammy 0.0.6-1.1 amd64

...which leads me to think only 1.43.0-1 is available for installation by apt-get, and that it's already installed.

But libuv's GitHub site indicates that there are newer releases.

How can I get libuv v1.45.0 (or later) on my Ubuntu instance with apt-get?

Although my immediate need is specific to libuv, I actually want to learn about this aspect of the Unix/Linux ecosystem in general: what is the relationship between drivers/packages/etc. that seem to be "released" (e.g. according to their GitHub pages) vs. what is "available" to package-managers, like apt-get? What should users do if they want a newer version of a package that isn't available from their package-manager? Should they download source and compile locally?

Update: Why do I need 1.45.0, i.e. why do I need a version more advanced than what's available from my package manager?

My Linux box is a development environment, where I need to compile to host (i.e. we can disregard cross-compiling for the context of this question). The application I need to compile (not written by me) has a reliance on uv_timespec64_t, which was apparently introduced in libuv v1.45.0 per this git merge/diff).

Thus, that is the premise of this question: I need to compile (to the host) an application that has a dependency on a feature from a newer version of libuv than my Linux distro's package manager offers.

Update: This question has a related, follow-up question here: Why do different Linux distros have different package formats (and package managers)?

StoneThrow
  • 1,717
  • It might be helpful if you clarified why you need v1.45. Is there something you want to install or run that requires it? – Shadur-don't-feed-the-AI Dec 12 '23 at 08:21
  • @Shadur - I've added verbiage to the post in the Update section as to why there was the perceived need for v1.45.0. – StoneThrow Dec 12 '23 at 21:24
  • 1
    This doesn't belong in the answer below, but helps explain why that picture below is so important. Don't make a FrankenDebian. The explanation given there applies in both directions. Although Ubuntu is a "child" of Debian, a "parent" repository, should never be added to a child. The other direction also applies, Ubuntu's "child" repos should not be added to the parent. This breaks the repository locking concept I described in the answer. I'll try to relate this comment somewhere below. – eyoung100 Dec 13 '23 at 16:31

2 Answers2

3

Trunks and Trees

While @TechLoom answered your question regarding libuv, allow me to answer you question regarding the Linux ecosystem. Let's start with this pictorial timeline

Open that up in a new browser tab, and note that there are 5 major trunks:

  1. Slackware
  2. Debian
  3. Red Hat, who went corporate, and the free variant is referred to as Fedora
  4. Enoch, who had a very short life, and became Gentoo
  5. Arch

Each of those branches, and hence all the child branches are defined mainly by the package management system in use.

  • The base Slackware uses zip/unzip/tar. The package is unzipped and compiled manually
  • Debian, of which Ubuntu is a child, uses APT - the Advanced Packaging Tool IIRC
  • Red Hat/Fedora uses RPM - RPM Package Manager
  • Enoch and its children compile everything from scratch using scripting. Imagine Slackware, but automated and configurable
  • Arch is a hybrid, that has held up really well over the years. Users can have a completely binary packaged system, i.e. packaged like Debian, or a completely compiled system like Enoch, or a mixture of both.

Now, as for how the ecosystem is connected. Each package manager is configured to connect only to its specified package tree, also called a repository. Debian-based systems connect to APT based trees, where you can download and install .deb files. Each of these package managers allows users to install custom trees. Ubuntu-based systems call them PPAs, or Personal Package Archives.

Release Cycles

Each distribution, regardless of the package manger has a release cycle. Release cycles can be thought of as "locked repositories" or using the tree analogy: "healthy trees that don't grow anymore." The repositories only contain packages that belong to that certain release. In general, packages installed by the release are never altered, and only updated in rare cases i.e., when a critical bugfix is released (which is why you cannot find libuv-1.45 in the jammy release), but if you look in mantic and noble, the next few codenames for Future Releases, you can see the package has been bumped (see Version Bumps below). Software like browsers and mail clients are generally released to the contrib(short for contributed) repository, which doesn't interfere with the main repository. In Debian's terminology, I believe they call their contributed repository universe, which fits rather well (every piece of user software under the sun can be put there). Each added package is compiled against the libraries and tools in the main repository, packaged and uploaded to the universe repository. This imitates the "locked repository" concept for software added by users or companies.

In Ubuntu's case the release cycle generally occurs twice a year (once in April, and once in October, barring a minor version update [the 3rd version number]). You can see this by looking at the Ubuntu Release List. The accepted practice is to only use packages available in your release until that package is updated by the maintainer.

Note that some distributions use a rolling release model, specifically those that are source based. I can issue an update command on my source compiled Gentoo box, rebuild packages, and an hour later perform the same update and possibly update the same packages again.

Even our friends, or enemies depending on your preference, over at Microsoft have adopted a Release Model starting with Windows 10. The current release of Windows 11 is versioned as 23H2, or the 2nd half of 2023. The first major version of Windows 10 I remember was 1903, referring to March 2019. While Microsoft's "tree" isn't publicly available it is used to integrate updates based on bug fixes and user requests into future versions of Windows.

Why Version Locking Is Important

To understand why the locked concept is so important, imagine you owned a BMW anything. BMW's are mostly all hand built and hand tuned. Let's say that we decide we want to add Feature X from the 2025 model to our model we bought in 2023 without talking to BMW first.

  • We buy the part needed to enable Feature X from the web
  • We go to install that part in the Dashboard and hook into the electrical system, and realize that the part for Feature X, requires a special connector.
  • We attempt to connect Feature X's part without the connector and end up damaging our 6-figure car
  • We contact BMW, and tell them I tried to connect feature X, but did more damage than upgrading. BMW sends us a connector and tells us to have the authorized mechanic put everything together

I bolded that last bullet to tie all this together. In the above "upgrade" BMW is maintainer of the "locked repository." BMW owns or can access all the parts for most all of it's cars when asked. The special connector doesn't exist outside the tree. In the same way you can only add software or upgrades to your Ubuntu version, a.k.a. the cars in this story, if the software exists in the repository. Mixing repositories from different versions causes complete breakage. If Feature X needs to be added or upgraded in a previous version, the software is backported, and get's added to that particular version's main repository (the mechanic), and the version continues operating as intended (the car is repaired).

Version Bumps

Version bumps, i.e., going from 1.43 to 1.45 are usually done as follows:

  1. The maintainer notices the new release, or a user files a version bump request with the maintainer
  2. The requested version is sent to the testing release to test for stability. In Ubuntu, this is known as the Future Release
  3. The package is tested, and either revoked or approved and released when the Future Release becomes the Current Release

LTS Releases

For users that need the stability, some distributions use the concept of a Long Term Service Release. These are usually preferred in areas with mission critical applications like a web server, firewall, or domain controller.

eyoung100
  • 6,252
  • 23
  • 53
  • @StoneThrow Finished. As for compiling, the package maintainer compiles the source as an iterative process before releasing it to the public. If any compile errors etc(hazards as you called them are found), the maintainer fixes those before releasing the source. As users who may compile software, it's expected that the maintainer will not put out a release that doesn't compile. That's one reason version numbers exist, as sane stopping points between continuous improvement. All packages are sourced, but the management of that source is what makes a distribution – eyoung100 Dec 12 '23 at 04:26
  • @Stephen Kitt Thanks for the edits! I wrote and rewrote sections of this last night, polishing and repolishing thinking I had squeezed everything into a pretty good answer. Your edits put it over the top into the perfection category. – eyoung100 Dec 12 '23 at 14:35
  • A question on terminology: in your Release Cycles section, does the term "repository" mean the "source" from which package managers (such as apt-get) pull packages? – StoneThrow Dec 12 '23 at 21:49
  • 1
    Yes, to my knowledge Red Hat and Debian based distributions refer to them repositories. Slackware and Gentoo refer to them as package trees. Arch also uses the term repository. – eyoung100 Dec 12 '23 at 21:58
  • 1
    I hadn't found a decent place to put this in the answer, but to see how all this compiling vs repository fits together, take a look at Gerrard Beekmans book and website on Linux From Scratach, an agnostic and "pure" version of Linux. By agnostic, I mean that there is no Package Management System. – eyoung100 Dec 12 '23 at 23:26
  • 1
    Post a new question. If you want to tie it to this one by linking it sone way. This answer is great but it's getting too long to add more. Readers may get lost in the details. The short answer is Dependency Management. Even though that's only 2 words, it will take an answer about as long as this one to explain. – eyoung100 Dec 13 '23 at 18:20
  • I forgot to add: Please link your question somewhere in your original with an Edit or here in a comment. I'll try not to repeat what others have said so we don't get it marked as a Duplicate. In the new question link back to this one somehow. On a side note, I'm glad you're reading what I wrote, as sometimes I fear these are too technical. – eyoung100 Dec 13 '23 at 18:36
  • The amount of detail in your answer is well appreciated, and has been fueling my learning and eagerness to learn more -- the best kind of answer one can hope for. So thank you, and, no, your answer is not too technical, and offers a good amount of direction to related issues to research. I've posted the discussed "follow-up" question here: https://unix.stackexchange.com/questions/764772/why-do-different-linux-distros-have-different-package-formats-and-package-manag – StoneThrow Dec 13 '23 at 18:46
  • I've finished my answer to the question. I'd like to edit it a bit but that will give you a start – eyoung100 Dec 13 '23 at 20:53
2

You can download the source from the github page.

https://github.com/libuv/libuv/releases

Then just extract out the source file and compile the program, then install it. All of the steps are on the github page.

https://github.com/libuv/libuv#build-instructions

$ sh autogen.sh
$ ./configure
$ make
$ make check
$ make install

Another option would be to look to see if anyone has a repository for the project. Then you could use "add-apt-repository" and then use apt like you want.

TechLoom
  • 66
  • 2
  • Note that unless you know what you're doing a lot better than the questions you've asked suggests, I don't recommend trying to manually compile software just to get a newer version than is available via package management. It might be helpful if you explained why you need 1.45 specifically; I feel like we may be looking at an XY problem. – Shadur-don't-feed-the-AI Dec 12 '23 at 08:21