Começo lembrando que "pacote" no Linux são os softwares, programas, bibliotecas, aplicativos, etc que podem vir isolados ou em conjunto de pacotes mas são chamados de "pacote" (package). É uma denominação genérica.

Backports são pacotes recompilados principalmente de estado "testing" (pacotes que passaram por testes e estão aptos a serem "promovidos" para "stable") e instáveis (apenas em alguns casos, por exemplo, atualizações de segurança e estão no estado "unstable" justamente por terem que passar por testes de uso antes de serem considerados adequados ao estado "testing"); então, sempre que possível esses pacotes serão instalados, muitas vezes sem novas bibliotecas, pois o pacote backport utilizará, quando necessário, as bibliotecas/dependências já existentes. Não confunda Backports com o termo "Backporting", como veremos a seguir.

Sobre backporting vamos considerar o seguinte:

Temos o pacote vol-1 (poderia ser apache-2.4, debian-12.2, etc). O pacote vol-2 é lançado, liberado (do Inglês, release) e você faz o download e o instala. Algum desenvolvimento/modificação ocorre em vol-2 e depois o vol-2.1 é lançado. Você atualiza, muitas vezes automaticamente e transparentemente, para vol-2.1. Ao mesmo tempo os desenvolvedores inventam outros novos produtos, desenvolvimentos e ramificações. É criado o vol-3, mas não é liberado, pois está em fase de testes (testing).

São colocadas mais atualizações/modificações nas ramificações que estão em circulação (vol-1, vol-2 e vol-3) e, em seguida, vol-3.1 e vol-4 são lançados. Você que tinha vol-2.algum_número atualiza para vol-3.1, mas você não quer e talvez nem possa instalar o vol-4, pois ele é drasticamente diferente e muito distante de vol-2.algum_número, ou seja, é desencontrado e/ou é uma dependência que não satisfaz o pacote como um todo e/ou se você instalá-lo ele pode quebrar o pacote/programa e pode tornar-se o famoso "pacote quebrado" e vir aquele famoso "Os pacotes a seguir têm dependências desencontradas:... Impossível corrigir problemas, você manteve (hold) pacotes quebrados.".

Como vol-4 já foi liberado, os pacotes vol-1.* e vol-2.* tornam-se obsoletos e não há razão para continuarmos desenvolvendo-os, entretanto, são mantidos como arquivos (archive) disponíveis para o usuário durante algum tempo até saírem de circulação e irem para o arquivo final em algum disco de dados/backup do(s) desenvolvedor(es) e/ou da empresa.

Eventualmente o vol-4.1 é lançado, mas um problema de segurança é detectado e logo corrigido e uma nova versão com correção (patch) é lançada como vol-4.2. Todavia, o mesmo bloco/trecho de código e o mesmo problema existem numa versão anterior, em, por exemplo, vol-3.4. Daí é analisado o que mudou entre vol-4.1 e vol-4.2 e sabendo o que foi feito para corrigir o problema, adaptamos e aplicamos essas alterações em vol-3.4 e automaticamente é criado o pacote vol-3.5.

***Agora temos o pacote backport da correção da versão vol-4 (mais recente) para a versão vol-3 (anterior) e você atualiza para vol-3.5.***

Geralmente o backporting é automático e transparente ao usuário, pois o pacote corrigido é colocado no repositório oficial stable e vem num update/upgrade que você faz com apt-get, com yum, com dnf, com zipper, com pacman, etc, ou vem direto em atualizações automáticas, dependendo do pacote. Além de virem automaticamente, geralmente os pacotes corrigidos/modificados/melhorados/acrescentados são colocados também nos repositórios backports oficiais para que você possa instalá-los de acordo com a sua conveniência/necessidade.

Em suma, Backports são os repositórios com seus respectivos pacotes corrigidos/modificados/melhorados/acrescentados e Backporting é o ato (seja ele automático ou proposital) de atualizar um pacote de uma versão recente para uma versão anterior corrigida/atualizada em seu código fonte.

Lembrando que a numeração dos pacotes/softwares/programas não tem uma regra definida, porém tem uma aceitação geral no seguinte sentido:

• - O número mais à direita (o último) significa qualquer iteração, algum bug corrigido, alguma otimização, porém nada que altere as funcionalidades propostas pelo software/pacote, pode ser também alguma "perfumaria", uma modificação no layout, etc.
• - Os números do meio significam que alguma funcionalidade foi adicionada e/ou retirada do software, porém, sua proposta básica continua a mesma.
• - O número mais à esquerda (o primeiro) significa que algo da versão anterior sofreu uma mudança estrutural no código da nova versão.

Por exemplo, na versão "2" do programa existia uma funcionalidade para calcular a idade, porém na versão "3" o desenvolvedor entendeu que essa funcionalidade era inútil e removeu da aplicação.

Outro exemplo: na versão "4" não tinha fórum no site, porém, ao ser acrescentada essa funcionalidade foi lançada a versão "5" ou "4.6", depende do(s) desenvolvedor(es) a numeração; todavia, essa aceitação geral citada anteriormente estabeleceu-se por ser mais lógica (primeiro número, número do meio, último número), não tem uma regra específica e acredito que nem possa ter.

No Kernel Linux, por exemplo, a versão 2.6.39 foi seguida pela versão 3.0 e a forma como vinha sendo numerado o Kernel mudou a partir daí de acordo com uma sugestão do Linus Torvalds (https://lkml.org/lkml/2005/3/2/247):

As versões oficiais passaram a ter apenas dois números, exemplo, 6.2;

As versões estáveis passaram a ter três números, onde o terceiro número (último) indica a quantidade de correções feitas, por exemplo 5.3.12 (12 correções);

As versões de teste (kernel estável + patch) passaram a ser identificadas por rc (release candidate, candidata ao lançamento) – a versão 3.0-rc1, por exemplo, foi lançada depois da 2.6.39 e antes da 3.0.

Como podemos observar aqui (https://www.kernel.org/category/releases.html) não tem uma regra específica:

• P:O número da versão principal (4.x vs 5.x) significa alguma coisa?
• R: Não. O número da versão principal é incrementado quando o número após o ponto começa a parecer "muito grande". Não há literalmente nenhuma outra razão.

Os números "par-ímpar" ainda significam alguma coisa? Há muito tempo o Linux usava um sistema em que números ímpares após o primeiro ponto indicavam Kernels de pré-lançamento e desenvolvimento (por exemplo, 2.1, 2.3, 2.5). Este esquema foi abandonado após o lançamento do Kernel 2.6 e atualmente os Kernels de pré-lançamento são indicados com '-rc'.

Exemplo: versão 4.39. O número 39 após o ponto começa a parecer grande então lança-se a versão 4.4 ou 5.0 do Kernel. Além disso, tem o tempo:

• P: Quando a próxima versão principal do Kernel será lançada?
• R: O Kernel do Linux segue uma cadência de lançamento simples: Após cada lançamento da linha principal há um período de "janela de mesclagem" de 2 semanas durante o qual novos recursos principais são introduzidos no Kernel. Após o fechamento da janela de mesclagem há uma correção de bug de 7 semanas e um período de estabilização com instantâneos semanais de "candidatos a lançamento". Rc7 é geralmente o último candidato a lançamento, embora ocasionalmente possa haver lançamentos rc8+ adicionais se isso for considerado necessário. Portanto, para encontrar a data aproximada da próxima versão principal do kernel, pegue a data da versão principal anterior e adicione 9 a 10 semanas.

Se a versão do kernel que você está usando estiver marcada como "EOL", por exemplo 6.2.16[EOL], considere atualizar para a próxima versão principal (no caso 6.3), pois não haverá mais correções de bugs fornecidas para essa versão do kernel, EOL - End Of Line (Fim de Vida).

Em suma, adotou-se, de um modo geral, tanto no software livre quanto no software proprietário, o lançamento de versões beta, testing, rc, etc, que, de certo modo, originou o que se conhece hoje por esse termo "backporting" que nada mais é do que um procedimento natural e não tem como ser diferente porque quando você encontra alguma coisa errada a tendência normal é consertar, ainda mais se você depende dessa coisa para viver e/ou considera esse software/pacote como um filho seu, uma criação sua.

Uma tradução livre para o termo backport em se tratando de desenvolvimento/programação seria "voltar à porta" no sentido de voltar para consertar, arrumar, modificar, melhorar... enfim.

No caso dos repositórios recomenda-se escolher backports que atendam às necessidades do momento e não usar todos os backports disponíveis.

Lembre-se de que, embora os repositórios Backports geralmente ofereçam pacotes confiáveis e testados, eles podem não ser tão estáveis quanto os pacotes padrão do seu sistema.