Como instalar versões de pacotes não disponíveis no apt-get?

Troncos e árvores

Embora @TechLoom tenha respondido sua pergunta sobre libuv, permita-me responder a sua pergunta sobre o ecossistema Linux. Vamos começar com

Abra isso em uma nova guia do navegador e observe que existem 5 troncos principais:

1. Slackware
2. Debian
3. Red Hat, que se tornou corporativa, e a variante gratuita é conhecida como Fedora
4. Enoch, que teve uma vida muito curta, e se tornou Gentoo
5. Arco

Cada uma dessas ramificações e, portanto, todas as ramificações filhas são definidas principalmente pelo sistema de gerenciamento de pacotes em uso.

• 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

Os aumentos de versão, ou seja, passar de 1.43 para 1.45 geralmente são feitos da seguinte forma:

1. O mantenedor percebe a nova versão ou um usuário envia uma solicitação de atualização de versão ao mantenedor
2. A versão solicitada é enviada para a versão de teste para testar a estabilidade. No Ubuntu, isso é conhecido como Versão Futura
3. O pacote é testado e revogado ou aprovado e lançado quando a Versão Futura se torna a Versão Atual

Lançamentos LTS

Para usuários que precisam de estabilidade, algumas distribuições usam o conceito de Long Term Service Release. Eles geralmente são preferidos em áreas com aplicativos de missão crítica, como servidor web, firewall ou controlador de domínio.

Você pode baixar o código-fonte na página do github.

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

Em seguida, basta extrair o arquivo fonte, compilar o programa e instalá-lo. Todas as etapas estão na página do github.

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

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

Outra opção seria verificar se alguém possui um repositório para o projeto. Então você poderia usar "add-apt-repository" e depois usar o apt como quiser.