É muito comum lermos 2 afirmações, uma contrária à outra:
-
“Distros rolling-release podem apresentar problemas”, ou: – “Arch Linux dá muito problema”
-
“Nunca tive problemas com Arch Linux” (etc.)
A última semana parecia destinada a confirmar a 1ª afirmação – e mais uma vez comprovei que a melhor alternativa é “Keep Calm & Google Last Week”.
Arch Linux
Desde o Domingo retrasado, o comando yay -Sua resultava numa atividade tresloucada de compilação – e após meia-hora terminava em uma mensagem de erro.
Obs.: - Sempre faço primeiro a atualização geral dos pacotes oficiais pelo
pacman– e só depois uso oyaypara atualizar os pacotes do AUR. – As coisas não se misturam, e fica mais fácil identificar a causa de algum “problema”.
A proposta do yay era esta:
499 2022-10-02_05-43-35 date; yay -Sua; date
...
dependencies after install? [y/N] y
2 google-chrome (Installed) (Build Files Exist)
1 python2 (Installed) (Build Files Exist)
...
-> error making: python2
Sun 2 Oct 06:11:22 -03 2022
O Google-Chrome foi atualizado – mas não o python2, que apresentou aquele erro, após meia-hora tentando compilar.
Uma googlada rápida pelas palavras-chave mais relevantes (limite: última semana) indicou que muitas pessoas estavam enfrentando o mesmo problema – e que o python2 foi “deprecado” (ou algo assim). – Não quis removê-lo com todas as suas dependências, pois isso incluiria um plugin que gosto muito, do Gimp (e eu não queria perder tempo em longas pesquisas, naquele momento):
$ date; yay -Rc python2; date
Sun 2 Oct 07:14:36 -03 2022
checking dependencies...
:: libglade optionally requires python2: libglade-convert script
Packages (6) gimp-plugin-resynthesizer-2.0.3-2 pygtk-2.24.0-12 python2-cairo-1.18.2-4 python2-gimp-2.10.30-1
python2-gobject2-2.28.7-7 python2-2.7.18-5
Total Removed Size: 84.94 MiB
:: Do you want to remove these packages? [Y/n] n
-> exit status 1
Sun 2 Oct 07:15:20 -03 2022
Apenas deixei como estava, e continuei usando o Arch Linux até o Domingo seguinte – sem nenhum problema.
Ontem, voltei a evitar essa atualização “deprecada” – e continuei usando o Arch Linux – ainda sem qualquer problema:
$ date; yay -Sua; date
Sun 9 Oct 07:51:42 -03 2022
:: Searching AUR for updates...
-> Missing AUR Debug Packages: libkipi-debug
-> Flagged Out Of Date AUR Packages: libkipi
:: 1 Packages to upgrade.
1 aur/python2 2.7.18-5 -> 2.7.18-6
==> Packages to exclude: (eg: "1 2 3", "1-3", "^4" or repo name)
==> 1
there is nothing to do
Sun 9 Oct 07:51:55 -03 2022
Outra fonte de angústia, dúvidas, medo e agonia, é quando o pacman faz uma perguntinha safada – daquelas que o usuário “comum” não entende, e teme as consequências.
No início, eu googlava as palavras-chave (limite: 7 dias) – mas depois me acostumei a sempre aceitar a opção-padrão sugerida – e isso nunca me causou qualquer problema:
# date; pacman -Syyu; date
Sun 19 Jun 08:45:20 -03 2022
:: Synchronising package databases...
core 155.9 KiB 577 KiB/s 00:00
extra 1716.9 KiB 12.9 MiB/s 00:00
community 6.7 MiB 48.7 MiB/s 00:00
multilib 169.8 KiB 4.88 MiB/s 00:00
:: Starting full system upgrade...
:: Replace kwayland-server with extra/kwin? [Y/n] YES, Sir !
Bom… É claro que “problemas” sempre podem acontecer – inclusive, deletar uma partição por engano – e é por isso que pratico o dualboot desde 2009.
Isso me daria uma “bóia de salvação” caso o Arch Linux “quebrasse” – mas, lamento informar, até hoje isso nunca me aconteceu. – Há 5 anos, o Arch Linux tem sido o mais “sólido” de todos.
Manjaro
Ontem, o Manjaro parecia disposto a complicar minha vida. – O pamac (CLI) pediu que eu escolhesse entre 4 versões do openjdk, para atualizar o Google-Chrome e um tal ceph-libs:
Checking google-chrome dependencies...
Checking ceph-libs dependencies...
Choose a provider for java-runtime:
1: jre-openjdk 18.0.2.1.u0-1 extra
2: jre11-openjdk 11.0.16.1.u1-2 extra
3: jre17-openjdk 17.0.4.1.u1-2 extra
4: jre8-openjdk 8.345.u01-1 extra
Enter a number (default=1): 1
Escolhi a opção-padrão, como sempre. – Além disso, era a versão mais recente. – E ele resolveu instalar 127 pacotes, além de “compilar” o Google-Chrome e um tal de ceph-libs.
Tenho o mesmo hábito, de primeiro atualizar os pacotes oficiais pelo
pacman– e em seguida os pacotes do AUR, pelopamac.
A brincadeira começou a ficar séria, quando essa atividade tresloucada entupiu a partição-raiz de 30 GiB.
Googlei as palavras-chave mais relevantes (limite: última semana) e descobri que… “Provavelmente você nem precisa ceph-libs e pode removê-lo”.
# date; pacman -Rns ceph-libs; date
Sun 9 Oct 16:01:19 -03 2022
checking dependencies...
Packages (1) ceph-libs-15.2.17-1
Total Removed Size: 59.55 MiB
:: Do you want to remove these packages? [Y/n] y
:: Processing package changes...
(1/1) removing ceph-libs
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...
Sun 9 Oct 16:01:29 -03 2022
(sim, ainda era o pacote “oficial”, pois o do AUR não chegou a ser compilado e instalado).
Removi todos os pacotes órfãos, limpei o cache de pacotes do pacman e do pamac, esvaziei a pasta da compilação em /tmp (o espaço ocupado em disco caiu para 14,8 GiB), e finalmente pude atualizar o Google-Chrome – em 1 minuto:
To build (1):
google-chrome 106.0.5249.103-1 (106.0.5249.91-1) AUR
Edit build files : [e]
Apply transaction ? [e/y/N] y
Redcore Linux
Aproveitando que o Arch Linux e o Manjaro já estavam alugando meu tempo, o Redcore Linux resolveu dar sua contribuição. – O comando sisyphus upgrade --ebuild rodou uns 40 minutos, sem chegar a nenhuma conclusão sobre o que precisava atualizar, e acabei interrompendo com CTRL+C.
Embora seja uma distro rolling-release (tecnicamente, um Gentoo com facilidades), acaba de lançar uma ISO com novo codinome “Ratanabá” – e tratei de ler as Release Notes – pois o Google falha vergonhosamente quando o assunto é “Redcore Linux”, e seu Fórum tem apenas uns gatos pingados (registrar-se no Fórum é tarefa insana) e quase nenhuma atividade:
- bugfix: sisyphus não fica mais preso quando a lista de dependências é muito grande
Eureka! – Instalei a nova versão do sisyphus, em 2 minutos – e depois disso ele ficou lépido e faceiro, pronto para lidar com a mega-atualização:
# date; sisyphus install sisyphus --ebuild; date
Mon 10 Oct 09:58:53 -03 2022
These are the binary packages that would be merged, in order:
sys-apps/portage-3.0.38.1 app-portage/sisyphus-4.2209.1 app-portage/sisyphus-qt-4.2209.1
Total: 3 binary package(s)
Would you like to proceed? [y/N] y
O mega-upgrade – 1481 pacotes binários + 12 ebuilds para compilar – se realizou em exatamente 3 horas (das 10:02 até as 13:02), o que está dentro da experiência com esta máquina.
Conclusão?
Nesses 3 exemplos, o máximo que fiz foi: (a) Lidar principalmente com pacotes oficiais, limitando o AUR ao mínimo; (b) Usar comandos de modo “organizado”, para não embaralhar mil coisas; (c) Na dúvida, aceitar os padrões sugeridos; (d) Googlar as palavras-chave para encontrar colegas que acabam de enfrentar a mesma dificuldade na última semana.
Não citei o openSUSE Tumbleweed, porque não lembro quando foi a última vez que me vi perante dúvidas ou aflições com o zypper dup.
Também não citei o PCLinuxOS, porque nele não uso comandos (só o Synaptic) – mas neste caso basta ir ao Fórum. Em geral, um dos desenvolvedores já deu a solução exata. – A última vez foi em Agosto, quando uma atualização ameaçava remover UDisks2, ddcopy etc.
O Debian oferece muito mais emoções – mas, desde 2016, nunca parou de funcionar.
O Void, já não lembro se me deu algum susto, nem quando foi. – Por sinal, antes de algumas grandes atualizações, costuma atualizar primeiro o próprio xbps – e só depois atualiza o resto.
