Upgrade do Mageia 8 para Cauldron (Mageia9)

Mageia Cauldron identifica-se como “Mageia 9”, no momento •

Cauldron é a versão de desenvolvimento do Mageia — onde se prepara o próximo lançamento — depois, o lançamento seguinte — e assim por diante.

Comporta-se como um lançamento contínuo (rolling release) — mas não é feito para isso, nem se recomenda para uso comum. — É para desenvolvedores e testadores.

• Mageia adverte que o “Cauldron pode quebrar seu computador, devorar seus dados, incendiar sua casa ou matar seus gatinhos”. — Se você precisa de uma distro “confiável” para o seu trabalho, fique sempre com a versão “estável”.

Em suma: é a versão de teste. — É como instalar Mageia 9 beta2, para ver o desenvolvimento final da próxima versão — e não parar mais de acompanhar os desenvolvimentos posteriores... Mageia 10... Mageia 11... etc.

Em vez de instalar, optei por fazer upgrade do meu Mageia 8 (stable) para Cauldron (testing) — de modo a preservar, na medida do possível, os pacotes que adicionei nos últimos 2 anos, as configurações em /etc e tudo mais.

• Isto não é um “tutorial”! — É só um registro para lembrar o que fiz, e como fiz — inclusive, erros... e desobediência às recomendações oficiais.

Índice

• Roteiro
• Bem-vindo ao Mageia Cauldron
• Ajuste fino
• Escovando bits
• Conclusões
• Por que Cauldron?
• E por que não via DNF?

Roteiro

Atualização do Mageia 8, antes de iniciar o upgrade para Cauldron

Leia as recomendações oficiais com atenção.

Basicamente — pelo urpmi:

1. Atualizar o Mageia estável
2. Remover os Repositórios da versão estável
3. Adicionar os Repositórios do Cauldron
4. Testar o upgrade (download e simulação)
5. Fazer o upgrade

Por distração, pulei o teste — e fiz logo o upgrade — o que é um perigo!

Em negrito, no histórico do bash — que não registrou a atualização inicial (imagem acima: 11:35):

# history
  776  2023-07-04_11-42-32  # dnf --version
...
  784  2023-07-04_12-25-49  # rpm -qa | sort > packages-installed-Mageia8.txt
...
  786  2023-07-04_13-01-43  # urpmi.removemedia -a
  788  2023-07-04_13-02-51  # urpmi.addmedia --distrib 'http://mageia.c3sl.ufpr.br/distrib/cauldron/x86_64/'
  790  2023-07-04_13-06-21  # systemctl stop dnf-makecache.service
  791  2023-07-04_13-06-41  # systemctl stop dnf-makecache.timer && systemctl daemon-reload
  792  2023-07-04_13-11-02  # date; urpmi --auto-update --auto --force; date
  793  2023-07-04_13-10-03  # script upgrade_log-1.txt
...
  797  2023-07-04_13-44-26  # rpm -qa | sort > packages-installed-Mageia9-Cauldron.txt
  799  2023-07-04_13-49-40  # urpmi --clean

Acima: - Depois do urpmi --auto-update, verifiquei se o dnf estava instalado (estava) — pois neste caso podia ser bom parar o dnf-makecache pelo systemctl. — Isso era uma recomendação antiga (de que dnf-makecache podia travar o upgrade via urpmi), mas não sei se ainda é necessária.

Pelo comando rpm, salvei uma lista dos pacotes instalados no Mageia 8.

Removi os repositórios do Mageia 8 pelo comando urpmi.removemedia -a.

Comando urpmi.addmedia para Cauldron x86_64 de um espelho específico

Adaptei o comando urpmi.addmedia para adicionar Cauldron e a arquitetura x86_64 — de um espelho específico.

• Mecanismos de escolha automática de espelhos mais “próximos”, ou  “mais responsivos”, são muito úteis para quem começa a usar distros Linux, ou não quer gastar tempo e neurônios — mas “o melhor da hora”, nem sempre é o melhor a médio e longo prazo. — Já usei dúzias de espelhos do Brasil e do exterior, e sei em quais posso confiar, levando em conta também as conexões até a minha cidade.

Parei o serviço dnf-makecache — e iniciei o Typescript, para registrar todas as mensagens do upgrade. — O histórico só registra o comando Typescript no final da gravação, ou seja, após o comando de upgrade (embora com o horário anterior).

Pelo comando rpm, salvei uma nova lista dos pacotes instalados — agora, no “Mageia 9” Cauldron — e limpei o cache de pacotes baixados pelo urpmi.

Dolphin parou de funcionar no meio do upgrade para Cauldron

Recomenda-se não fazer o upgrade do Mageia dentro de uma sessão desktop, mas é claro que não obedeci. — Perto do final, o Dolphin não conseguia mais abrir outras pastas — mas o Kate e o gnome-screenshot continuaram gravando seus arquivos normalmente, e pude documentar o processo todo, sem lacunas.

urpmi alterna download e instalação (e remoção!), por grupos de pacotes

O upgrade, propriamente dito, se realizou em 11 minutos (13:11 às 13:22), com uma conexão de 480 “megas” (480 Mbit/s  = 57,22 MiB/s), alternando download, instalação (e remoção!) de grupos de pacotes.

Script started on 2023-07-04 13:10:03-03:00

# date; urpmi --auto-update --auto --force; date
Tue  4 Jul 13:11:02 -03 2023

(...)

You should restart your computer for dbus, glibc, kernel-desktop, systemd
Tue  4 Jul 13:21:51 -03 2023

exit

Script done on 2023-07-04 13:22:18-03:00

Download, instalação e remoção de grupos de pacotes pelo urpmi

Ao contrário do upgrade pelo dnf — que baixa todos os pacotes de uma vez, e depois reinicia o PC para aplicar as alterações fora do ambiente desktop — o urpmi baixa e instala um grupo de pacotes de cada vez, ao mesmo tempo em que já vai removendo os grupos de pacotes substituídos.

Isso é um perigo — caso haja qualquer falha ou interrupção no meio do processo!

Por isso, é recomendado fazer o download de todos os pacotes, seguido de um teste que apenas simula o upgrade, para detectar possíveis falhas — antes de realmente fazer o upgrade — mas por distração, não notei que eu tinha esquecido de adicionar esses 2 parâmetros ao comando:

 # urpmi --auto-update --auto --download-all --test

Felizmente, a energia elétrica não caiu durante o processo — e não houve falha no download de nenhum pacote.

Foi por decisão consciente que — contra todas as recomendações — decidi fazer o upgrade dentro da sessão KDE Plasma, e com vários aplicativos abertos.

Mas as falhas e erros devem-se ao fato de que li coisas demais: — instruções de upgrade para Cauldron, instruções de upgrade do Mageia 7 para Mageia 8, instruções de upgrade pelo urpmi e pelo dnf — e fiz uma bela confusão com esse excesso de leituras, sem parar para resumir um roteiro simples e claro, e conferir com atenção, antes de começar.

• Para instalar o Arch pela primeira vez, li 300 vezes mais — mas tive o cuidado de resumir um roteiro simples e claro. — Agora, resolvi fazer o upgrade, e agi de improviso, o que não é recomendável.

Por isso, registro aqui apenas o que fiz — não um “roteiro ideal” — e evito falar de outros métodos de upgrade (para não confundir, e porque não testei).

Bem-vindo ao Mageia Cauldron

Grub do Mageia Cauldron consegue detectar e carregar openSUSE em BtrFS

Ao reiniciar o computador, o Grub do Mageia Cauldron tinha assumido a prioridade de boot no UEFI Bios.

A sessão KDE exibiu o Painel aos 20 segundos uptime (Auto Login). — A média das 6 inicializações seguintes foi de 17 segundos até exibir o Painel. — Ver “Conclusões”, adiante.

Eu ainda não tinha re-configurado os repositórios do Google — mas o Chrome e o GoogleEarth não foram removidos.

O MSEC tinha voltado à configuração padrão — “Enable periodic security checks”, que desativei outra vez — mas manteve o acesso que eu tinha concedido ao KDE Connect.

Atualização do Grub do openSUSE, meu Menu de inicialização

O Grub do Mageia Cauldron continua capaz de detectar o openSUSE, instalado em sistema de arquivos BtrFS, sem partição de /boot separada. — Devolvi a prioridade de boot ao openSUSE pelo efibootmgr — e atualizei seu Grub para detectar o novo Mageia Cauldron.

KDE-PIM a todo vapor, com 17+ processos Akonadi y otras cositas más

Aos 10 minutos (iddle) da 2ª sessão do Mageia Cauldron KDE, o uso de Memória RAM ficou em 1.384 MiB — 30% acima do uso no Mageia 8.

Isso me alertou de que o KDE-PIM estava em plena atividade, com 17+ processos Akonadi — entre outras coisas, que eu tinha desativado / removido do Mageia 8.

Isso também deu uma pista para o motivo de o número de pacotes instalados ter aumentado em 323 — de 2.696 no Mageia 8 para 3.019 no Mageia Cauldron.

• A causa talvez seja porque fiz upgrade com o parâmetro --force, ausente nas recomendações oficiais: — “force invocation even if some packages do not exist”. — Como não se podem invocar pacotes inexistentes, suponho que queira dizer “pacotes não-instalados”.

Remoção de dezenas de pacotes do KDE-PIM, pelo rpmDrake

Pelo rpmDrake, pesquisei PIM, Kmail, KAddressbook, Kontact, KOrganizer, KNotes, KAlarm, Akonadi etc., e removi quase tudo — com toneladas de dependências — poupando só o que ameaçasse remover pacotes úteis, ou quebrar o ambiente KDE.

Importante: - Preservo sempre o baloo e o baloo-widgets (+2 bibliotecas), que são indispensáveis ao ambiente Plasma KDE.

Removi também o dnf, que não pretendo usar.

Enfim, executei o urpme --auto-orphans para eliminar o que sobrou.

Com isso, o número de pacotes instalados recuou para 2.862 — o que ainda é 166 a mais do que eu tinha no Mageia 8 — e nos 2 boots seguintes, o uso de Memória RAM aos 10 minutos (iddle) recuou para 1015 MiB e 1.004 MiB, o que está mais próximo dos 1.068 MiB do Mageia 8 no mês anterior.

• Variações de até 40 MiB ocorrem a cada segundo — por isso, não vale a pena levar muito a sério pequenas diferenças no “uso inicial de Memória RAM” entre 2 distros — e se você tem mais de 4 GB RAM, não perca tempo com isso. Use a distro e o DE que quiser, e seja feliz!

Desabilitando alguns serviços do Plasma Search

Essa redução de uso de Memória RAM também se deveu, em parte, à desativação de vários Background Services, Desktop Effects e serviços do Plasma Search que eu não utilizo — mas que tinham sido reativados no upgrade para Cauldron.

Substituição do widget Weather pelo Weather2

Substituí o velho widget Weather — que ainda funcionava com a versão antiga do KDE Plasma — pelo Weather2.

Dynamic Word Wrap e Show Line Numbers no KWrite

As versões mais recentes do KWrite (e do Kate) perderam os atalhos para alternar (on / off) Dynamic Word Wrap (F10) e Show Line Numbers (F11). — F10 pode ser configurado manualmente — ao passo que F11 agora conflita com o atalho global, mas bastou configurar para sempre exibir a numeração das linhas.

speedtest-cli e corona-cli funcionam normalmente

O speedtest-cli funciona normal (com as limitações by Ookla).

O corona-cli só precisou ser atualizado (por comando npm), pois há tempos eu não fazia isso.

Tue  1 Nov 13:43:02 -03 2022                               Tue  4 Jul 16:50:51 -03 2023

medium "Core Release (distrib1)" is up-to-date             medium "Core Release" is up-to-date
medium "Core Updates (distrib3)" is up-to-date             medium "Core Updates" is up-to-date
medium "Nonfree Release (distrib11)" is up-to-date         medium "Nonfree Release" is up-to-date
medium "Nonfree Updates (distrib13)" is up-to-date         medium "Nonfree Updates" is up-to-date
medium "Tainted Release (distrib21)" is up-to-date         medium "Tainted Release" is up-to-date
medium "Tainted Updates (distrib23)" is up-to-date         medium "Tainted Updates" is up-to-date
medium "Core 32bit Release (distrib31)" is up-to-date      medium "Core 32bit Release" is up-to-date
medium "Core 32bit Updates (distrib32)" is up-to-date      medium "Core 32bit Updates" is up-to-date
medium "Nonfree 32bit Release (distrib36)" is up-to-date   medium "Nonfree 32bit Release" is up-to-date
medium "Nonfree 32bit Updates (distrib37)" is up-to-date   medium "Nonfree 32bit Updates" is up-to-date
medium "Tainted 32bit Release (distrib41)" is up-to-date   medium "Tainted 32bit Release" is up-to-date
medium "Tainted 32bit Updates (distrib42)" is up-to-date   medium "Tainted 32bit Updates" is up-to-date
medium "earth_x86_64" is up-to-date
medium "chrome_x86_64" is up-to-date

2023-07-05 12:07:53

# urpmi.addmedia --update chrome_x86_64 http://dl.google.com/linux/chrome/rpm/stable/x86_64
adding medium "chrome_x86_64"
    http://dl.google.com/linux/chrome/rpm/stable/x86_64/media_info/synthesis.hdlist.cz

# rpm --import https://dl-ssl.google.com/linux/linux_signing_key.pub

# urpmi.addmedia --update earth_x86_64 http://dl.google.com/linux/earth/rpm/stable/x86_64
adding medium "earth_x86_64"
    http://dl.google.com/linux/earth/rpm/stable/x86_64/media_info/synthesis.hdlist.cz

Acima: - Os “canais” (medium; media; distrib) do Mageia Cauldron, adicionados pelo urpmi.addmedia, são os mesmos que eu tinha no Mageia 8.

Só alguns desses “canais” vieram habilitados, ao instalar o Mageia 8 (distrib1, 3, 11, 13, 36, 37, se não me engano); e os outros, habilitei depois. — Isto sugere que, ao “remover todos”, essa configuração foi preservada; e ao usar o comando urpmi.addmedia para escolher “Cauldron”, ele já sabia quais “canais” deviam ser habilitados.

Só precisei adicionar os repositórios do Google e obter sua chave pública.

• No caso do GoogleEarth, mais tarde substituí “http” por “https”, só para seguir a versão atual da Wiki — mas isso não trouxe nenhuma atualização do pacote — e a busca por cidades, ruas etc. continua sem funcionar (como já não funcionava no Mageia 8).

Tudo mais — o KDE Plasma, os Aplicativos KDE e demais aplicativos que eu já tinha no Mageia 8 — continua funcionando no Mageia Cauldron.

No Gimp, mantiveram-se inúmeras configurações — mas outras, tive de refazer, tal como já havia acontecido, por exemplo, na transição para o Gimp 2.10.

É possível que eu encontre mais alguma coisa, em outros aplicativos, que ainda não abri até o momento. — Faz parte da vida.

Falha em “Abrir com Gimp”, no Menu de contexto do Gwenview

O único problema novo (falta solucionar!), é que no Menu de contexto do Gwenview, ao clicar em “Abrir com Gimp”, abre uma nova instância do Gwenview. — Isso é chato, pois uso muito, no dia-a-dia. — Mas no Dolphin, o Menu de contexto “Abrir com Gimp” funciona sem qualquer problema.

O yt-dlp está encontrando muitos “erros”, embora a versão seja de Junho 2023 — mas não tenho usado outras distros, para comparar. — Talvez o Youtube tenha colocado novas barreiras, a serem dribladas pela próxima versão do pacote.

Ajuste fino

“MyPlaces” importado do Arch Linux

No GoogleEarth, importei os “Meus Lugares” do Arch Linux, movi seu conteúdo para os “Meus Lugares” do Mageia, reorganizei e salvei. — Depois salvei uma cópia na minha partição de documentos (Warehouse, com backups semanais).

Icons-only Taskbar, mais discreto

Agora que estou no Mageia Cauldron por um longo período, troquei o Taskmanager (Gerenciador de tarefas) pelo “Icons-only Taskmanager” — que é mais discreto e facilita trabalhar com muitas janelas — em ordem “manual” (Sort: Manually) e sem agrupar (Do not group).

Ocupação da pasta ~/.cache

Meia hora antes do upgrade, no dia 4 Julho, a ocupação da partição /home estava em 6,47 GiB — mas no dia 10 (menos de uma semana depois!). já tinha chegado a 11,6 GiB — um aumento vertiginoso, que nunca vi em nenhuma distro.

Pelo Filelight, verifiquei que havia 4,3 GiB em ~/.cache/tracker3; e mais 1,5 GiB em ~/.cache/thumbnails. — Costumo deletar manualmente os Thumbnails, que proliferam (e se acumulam para sempre), quando vejo alguma partição /home chegar perto da lotação máxima; — mas nunca vi nem ouvi falar de tracker.

Numa pesquisa rápida, vi que é um indexador do Gnome — equivalente, talvez, ao baloo_file do KDE (que removo sempre que encontro). — Segundo meus registros, o tracker e o tracker-miners foram instalados como dependências do Foliate, em Setembro 2020 (mas ficaram quietos, até a semana passada).

Tentei remover o tracker, mas o urpme avisou que isso removeria 147 pacotes — incluindo Gimp, Chrome, LibreOffice, lsb, mate-polkit (?), plasma-desktop, rpmdrake, Xsane — a maioria dos quais, já estavam instalados, antes do tracker, e por isso é difícil acreditar que não possam viver sem ele.

Mas consegui remover o tracker-miners — e aproveitei para remover o gnome-desktop e o Firefox, que não uso. — Depois disso, não apareceram novos arquivos na pasta ~/.cache/tracker3 (que esvaziei).

Esvaziar a pasta ~/.cache/thumbnails foi mais complicado, pois eram tantos, que o rm pediu arrego — mas o comando find conseguiu. — E restavam muitas outras subpastas em ~/.cache, que eu não iria deletar em massa, sem pesquisar o que são, e as possíveis consequências.

Acabei ficando com um meio-termo: — Deletar tudo que não é acessado há mais de 1 ano — e criei um agendamento para fazer isso 15 minutos após o boot (para não interferir no registro do uso de RAM, aos 10 minutos):

$ crontab -l
@reboot echo ' ' > done.txt
@reboot sleep 600; bash RAM.sh
@reboot sleep 780; bash VERSIONS.sh
@reboot sleep 900; find ~/.cache/ -type f -atime +365 -delete

Depois dessas manobras, a ocupação da pasta /home caiu para 4,12 GiB — e, o que é mais importante: — parou de aumentar naquele ritmo alucinado.

Resolvi mover meus scripts para ~/bin — e eles continuaram funcionando pelo Conky e por comandos manuais, pois a pasta já estava no $PATH — mas o cron não os encontrou mais.

Em geral, o PATH do ambiente cron é /usr/bin:/bin, e por motivos de segurança, ele não lê o perfil de usuário (.bash_rc, .bash_profile). — Pode-se redefinir o PATH no início do crontab, mas para evitar um longo estudo (e possíveis erros), achei mais simples apenas indicar o “caminho” dos scripts:

$ crontab -l
@reboot echo ' ' > done.txt
@reboot sleep 600; bash /home/flavio/bin/RAM.sh
@reboot sleep 780; bash /home/flavio/bin/VERSIONS.sh
@reboot sleep 900; find ~/.cache/ -type f -atime +365 -delete

Escovando bits

Não consegui remover Flatpak. — O comando urpme avisa que isso implica em remover partes do KDE. — Segundo meus registros, Flatpak foi instalado por uma simples atualização do sistema, em Julho 2020.

Também não pude remover PackageKit. — O comando urpme diz que isso implica em remover Dolphin e outras coisas essenciais. — Isso parece loucura, e desconfio, cada vez mais, que se deva a alguma configuração exagerada, de considerar pacotes “sugeridos” como se fossem “dependências” cruciais (como no openSUSE).

Fiquei alarmado ao perceber que, às vezes, urpme desinstala pacotes sem pedir confirmação — e ainda não sei, em quais casos — o que torna essa brincadeira um tanto perigosa, até que eu aprenda mais.

Um caso típico são os metapacotes “task” — como o task-plasma5, que deixou órfãos ksystemstats e plasma-systemmonitor.

Para não perder a comodidade do comando urpme --auto-orphans, tive de marcá-los como “instalados explicitamente”. — Para isso, basta tentar reinstalá-los, pois nesse caso o urpmi limita-se a retirá-los da lista de pacotes órfãos. — Este comando facilita a tarefa:

# date; urpmi $(urpmq --auto-orphans -f); date
Thu 13 Jul 14:23:53 -03 2023
Packages kernel-desktop-6.3.9-2.mga9.x86_64, ksystemstats-5.27.5-1.mga9.x86_64, plasma-systemmonitor-5.27.5-1.mga9.x86_64 are already installed
Marking kernel-desktop as manually installed, it won't be auto-orphaned
Marking ksystemstats as manually installed, it won't be auto-orphaned
Marking plasma-systemmonitor as manually installed, it won't be auto-orphaned
writing /var/lib/rpm/installed-through-deps.list
Thu 13 Jul 14:23:55 -03 2023

Infelizmente, isso também foi aplicado ao Kernel 6.3.9-2 — que agora não será mais eliminado automaticamente, na hora devida. — Vou ter de removê-lo, eu mesmo, quando não for mais necessário.

Verificando pelo rpmDrake os meta-pacotes instalados

Um exame pelo rpmDrake, filtrando “Meta packages”, mostrou que ficaram apenas task-pulseaudio, basesystem, task-obsolete, task-x11 e task-codec-video — nos quais prefiro não mexer, por enquanto.

Importante: - O usuário do Mageia não precisa perder tempo com esse tipo de minúcias, pois o sistema é feito para ser amigável e sólido. — Faço essas coisas só para explorar as entranhas da distro e entender seus mecanismos internos, como um guri que desmonta os brinquedos. — Com 16 GB RAM e uma partição de 30 GiB, não há necessidade de “economizar bits”.

Opção “Imprimir para um arquivo”, no LibreOffice Calc

Eu já tinha removido hplip desde Outubro 2020 — e agora removi o que havia sobrado do cups — um teste que eu queria fazer há muito tempo, pois me desfiz de minha última impressora há mais de 20 anos.

Após reiniciar, o Chrome continua imprimindo em PDF (CTRL+P) — e no LibreOffice ainda funciona o “Export as PDF” (que prefiro). — Para “imprimir” no LibreOffice, preciso selecionar manualmente “Print to file”, enquanto não descobrir como mudar o padrão “Generic printer”

Conclusões

Quadro 1 - Estado das minhas distros em 11 Junho 2023

Quadro 1 - A “usabilidade” do Mageia Cauldron, para mim, não se alterou, em relação ao Mageia 8 do mês passado, quando fiz a última verificação do “estado” das distros instaladas no meu PC. — Sinto um impulso de afirmar que, agora, o Mageia se tornou uma de minhas “distros preferidas” — mas a razão fria me garante que isso é entusiasmo com “brinquedo novo”.

Quadro 2 - Mageia Cauldron face às outras distros no mês passado

Quadro 2 - Tudo no Mageia Cauldron está “mais atual” — e vai continuar “sempre atual”, pois Cauldron é sinônimo de “atualização permanente” — mas o grande “ganho” é que “não perdi nenhuma usabilidade” que eu tinha antes.

Isso não é pouca coisa. — Significa que todo novo aprendizado pode me levar para frente, em vez de perder tempo consertando retrocessos. — Com a diferença, de que uma distro “atual” me anima muito mais a investir no aprendizado e solução de problemas, do que uma distro “estagnada” durante 2 anos.

Boot times:

2023-07-04   18:38   Mg   18’’
2023-07-05   07:25   Mg   17’’
2023-07-06   10:26   Mg   17’’
2023-07-09   14:04   Mg   17’’
2023-07-10   14:48   Mg   17’’
2023-07-11   17:29   Mg   18’’    average 17’’

RAM usage 10 min uptime (iddle):

2   1015  MiB
3   1004  MiB
4    998  MiB
5   1011  MiB
6   1003  MiB
7   1007  MiB
8   1006  MiB    average: 1006  MiB

Other SO's - just 1 sample, back in 11 June:

Void                      878  MiB
PCLinuxOS                 921  MiB
Slackware 15              940  MiB
MX Linux 21               940  MiB
Redcore                 1,001  MiB
Mageia Cauldron         1,006  MiB
Manjaro                 1,031  MiB
KDE Neon (Jammy)        1,049  MiB
Arch                    1,059  MiB
Fedora 38               1,139  MiB
openSUSE Tumbleweed     1,210  MiB
Debian testing          1,211  MiB

A média de 17 segundos do boot até exibir o Painel do KDE não representa grande melhora em relação aos 18 segundos da média anterior — pois em Maio e Junho também houve 5 registros de 17 segundos — e apenas 2 casos puxaram a média um pouco para cima.

Quanto à redução do uso inicial de Memória RAM, pode ter sido causada por um ajuste mais rigoroso na desativação de serviços que não  uso.

Enfim, mantive a data de instalação: Julho 2020 — porque, de fato, é a instalação que continuo usando — agora, como “Cauldron”.

Por que Cauldron

Fiz o upgrade do Mageia 8 (stable) para o Mageia Cauldron (testing) para me antecipar ao próximo lançamento do Mageia 9 — mas também para me livrar daquela rotina de instalar uma nova versão a cada 2 anos, com todo o trabalho de configurar repositórios, adicionar pacotes etc. — O upgrade preserva a maior parte do trabalho já realizado para adequar a distro ao que eu preciso.

Me acostumei às distros Linux de lançamento contínuo — 6½ anos com o Debian testing, 6 anos com o Arch, 5 anos com o PCLinuxOS, 4 anos com o openSUSE Tumbleweed e com o Void — e acabei perdendo o interesse por distros “estáveis”, ou de “lançamento fixo”, que ficam estagnadas durante 2 anos, e depois dão trabalho.

Nesse período, instalei o Mageia 6 sta2 (uns 4 meses antes do lançamento); o Mageia 7 beta2 (uns 3 meses antes do lançamento); e o Mageia 8 alpha1 (uns 6 meses antes do lançamento). — Portanto, lidei pelo menos 3 vezes com a fase final de desenvolvimento dessa distro; e nunca tive problemas com isso. — Havia muitas atualizações, pacotes sempre nas versões mais recentes. Quase um rolling-release! Mas após os lançamentos, as coisas estagnavam e perdiam a graça.

O que fiz agora foi evitar mais uma instalação — que neste momento, seria a do Mageia 9 beta2 — e várias outras, nos próximos anos.

E por que não via DNF?

Aviso para não misturar dnf e urpmi

Já fiz 8 upgrades do Fedora pelo dnf — do 30 para o 31, para o Fedora 32 — e não parei mais, até o Fedora 38 (por enquanto), sem nenhum problema.

De início, até achei que poderia ser mais cômodo fazer o upgrade do Mageia pelo dnf — mas vi que não é bom alternar o uso dele com o do urpmi.

Há motivos para não misturá-los.

A Wiki do Mageia é clara: — “URPMI e DNF usam métodos diferentes para rastrear órfãos. Se você usar os dois, nunca deve usar a funcionalidade automática de nenhum deles para remover órfãos”.

Enfim, já uso o dnf no Fedora — e no Mageia prefiro continuar explorando o urpmi.

___________________
• Publicado em 5 Julho 2023 e desenvolvido até 7 Agosto 2023.

— … ≠ “•” ≠ … —

PC desktop UEFI / GPT

• Transição para hardware UEFI-GPT
• Arch Linux - install, config
• Debian testing - install, config
• Linux Mint 20 (beta) "Ulyana" + Plasma KDE
• Upgrade para o Fedora 32
• Void + KDE
• MX Linux 19.2 KDE Beta 2
• KDE Neon upgrade 20.04 Focal Fossa
• Slackware by Alien BOB
• Adicionando HDD a 11 distros Linux em dualboot
• Slackware 15 alpha1
• Manjaro - instalação e configuração
• PCLinuxOS KDE Darkstar - instalação de substituição
• MX Linux 21 Wildflower KDE - instalação de substituição
• Linux, dualboot, discos, partições e backups
• Redcore Linux - instalação e configuração
• Multiboot de 12 distros Linux
• Upgrade do Mageia 8 para o Cauldron (Mageia9)
• MX Linux 23 “Libretto” KDE - instalação e configuração