Translate

segunda-feira, 31 de julho de 2023

MX Linux 23 “Libretto” KDE

MX Linux 23 “Libretto” KDE
MX Linux 23 “Libretto” KDE •

O site do MX Linux oferece instruções simples e claras de “Migração” do MX-21 para o MX-23 — na verdade, uma reinstalação, preservando a partição /home e uma lista dos pacotes adicionados pelo usuário, gerada pelo “user-installed-packages” (a ser instalado no MX-21) — que depois utilizará essa lista para adicioná-los na nova instalação, com direito a revisá-la caso-a-caso.

A Wiki do MX Linux também oferece instruções para quem prefere fazer upgrade da instalação anterior (MX-21 para MX-23) — caso sinta-se habilitado a enfrentar várias tarefas por comandos e resolver eventuais problemas. — Descartei essa opção, pois alguns pacotes podem ter sido acrescentados / substituídos / removidos, e preferi garantir uma instalação “padrão” do MX Linux 23.

Optei por instalar o MX Linux 23 em uma nova partição (provisória) — testar seu funcionamento — e só depois sobrescrevê-la na partição onde estava meu MX Linux 21 (plenamente funcional).

  • Isto NÃO é um “tutorial”. — É só um registro do que fiz — inclusive possíveis erros (para poder entendê-los e corrigi-los, no futuro).

Índice

  • Pacotes instalados pelo usuário
  • Download, sha256sum e K3b
  • Sessão Live MX Linux 23
  • Instalação
  • Teste da instalação
  • Substituição do MX-21
  • Pós-instalação

Anteriores

Pacotes instalados pelo usuário

Lista de pacotes instalados pelo usuário no MX Linux 21

Instalei no MX-21 o “user-installed-packages” e salvei a lista dos pacotes que eu havia adicionado naquela instalação — mas também salvei várias listas de todos os pacotes instalados, usando comandos apt, dpkg, zgrep:

apt list --installed                        > 12_2023-07-31_MX21_apt-list--installed.txt
dpkg --list | grep 'ii '                    > 12_2023-07-31_MX21_dpkg--list-grep-ii.txt
dpkg --get-selections | grep -v deinstall   > 12_2023-07-31_MX21_dpkg--get-selections-grep-v-deinstall.txt
dpkg-query -l                               > 12_2023-07-31_MX21_dpkg-query-l.txt
zgrep " installed " /var/log/dpkg.log*      > 12_2023-07-31_MX21_zgrep-installed-var-log-dpkg-log.txt

Download, sha256sum e K3b

Verificação da imagem ISO do MX Linux 23 KDE pelo sha256sum

Baixei o MX-23 KDE 64 bit pelo KTorrent, verifiquei a integridade pelo sha256sum e “queimei” pelo K3b em DVD, para guardar.

Sessão Live MX Linux 23

Escolha do Idioma, Fuso horário e Teclado, antes de iniciar a sessão Live

Ao iniciar o PC pelo Live MX Linux 23, ele pré-seleciona a 3ª linha do Menu — Idioma, Teclado, Fuso horário — e a experiência já me ensinou que é melhor fazer essas escolhas antes de iniciar a sessão Live, para não perder tempo (e essas coisas já ficam configuradas para a instalação na máquina).

Ao terminar essas escolhas, ele vai para a 1ª linha do Menu de boot: — Iniciar a sessão Live MX Linux 23.

Criando uma partição proisória pelo KDE Partition Manager

Instalei Synaptic, gnome-screenshot, ttf-mscorefonts, iniciei meu próprio Conky, apliquei no ambiente Plasma KDE o Tema “MX Dark” — e pelo KDE Partition Manager criei uma partição provisória “Linux13” (29,3 GiB).

Instalação

Seleção das partições no instalador do MX Linux 23

No instalador do MX Linux 23, selecionei a partição “Linux13”, cliquei na seta para baixo no campo da coluna “Use for” (Usar como), e escolhi “/”. — Ele mudou o rótulo na coluna “Label”. — Eu podia ter mudado de volta, mas era só um rótulo provisório, sem qualquer significado no meu esquema.

Creio que alterou automaticamente para BtrFS na coluna “Formatar”, e eu cliquei na seta para baixo e escolhi ext4. — Tentei “Preservar”, mas a partição estava vazia, e por isso não tinha pasta /home que pudesse ser preservada. — Quando escolhi ext4, ele mudou a opção para “discard” (descartar), e costumo aceitar as opções-padrão, quando não sei bem o que significa.

  • Eu já uso BtrFS no openSUSE (Linux1), há 6½ anos, sem problema, mas não quero ter 2 distros com esse sistema de arquivos.
  • Anoto todos esses detalhes, dúvidas e hesitações, porque o MX Linux oferece uma quantidade enorme de recursos incomuns, que até hoje nunca explorei — pois prefiro experimentar 1 coisa de cada vez, para evitar confusão. — O instalador do MX Linux tem mudado bastante (desde o 17), o que me leva a ter muito cuidado com tudo que não entendo bem.

Tentei avançar (Next) — mas o instalador já havia detectado que o computador estava usando UEFI — e exigiu que eu escolhesse uma partição EFI.

Copiei “/boot/efi” (do aviso) e colei no campo ”Use for” — e ele automaticamente selecionou “Preserve” na coluna “Formatar” (e “noatime”, em “Opções”). — Isso é ótimo, pois ali estão as pastas EFI de outras distros, e formatar seria um desastre.

Ao clicar em Avançar (Next), o instalador apresentou um resumo: — “Reusar (não formatar) sda1 como /boot/efi” — e “Formatar sda17 para usar como /”.

Desativei criar Arquivo Swap, para manter o padrão das minhas outras distros

Na tela seguinte, ofereceu instalar o Grub (em ESP) — e a criação de um Arquivo Swap de 4 GiB. — Desativei a criação do Arquivo Swap (para não ficar diferente das minhas outras distros); e deixei desativado o suporte a Hibernação.

Opções de hostname e SMB (SaMBa) no instalador do MX Linux 23

Em outra tela, propôs o nome do computador (hostname) “mx”, e o domínio “example.dom”. — Aceitei ambos. — Desativei o servidor SMB (SaMBa) para Rede MS, pois só tenho 1 PC (e nenhum Windows).

Idioma (Localização), Fuso horário, Relógio do sistema, Serviços

Em seguida, ofereceu a possibilidade de alterar o Idioma / Localização, o Fuso horário, o Relógio do sistema e o formato das horas (24h). — Mantive as opções feitas antes de iniciar a sessão Live — e o padrão UTC para o Relógio do sistema.

Um botão permite inspecionar os Serviços — e aproveitei para desativar cups, pois não tenho impressora.

Usuário, Administrador, Auto Login e alterações da sessão Live Desktop

Na tela seguinte, inseri o nome de Login e a senha do Usuário. — Ativei a conta de Administrador (Root); o Login Automático (Auto Login); e a opção de Salvar as alterações feitas na sessão Live (mantê-las na instalação final).

Ao chegar nessa tela, a instalação do MX Linux 23 no SSD já estava 93% ou 96% completa, segundo a barra de progresso — e fez uma pausa, para permitir que eu alterasse alguma configuração, antes de prosseguir. — Ao clicar em Avançar (Next), ainda foram necessários mais 6 minutos (21:21 a 21:27) para o Grub / os-prober examinar as outras 27 partições, e detectar as 12 distros instaladas.

  • Um tempo perdido, pois não vou usar o Grub do MX Linux como “Menu de Inicialização” — mas há muito tempo já desisti de tentar desabilitar os-prober em sessões Live de instalação de qualquer distro. — Não houve uso excessivo nem aquecimento da CPU (37ºC a 40ºC), ao contrário do que já observei em outras distros.

Desmarcando o Reboot automático antes de fechar o Instalador

Ao finalizar a instalação do MX Linux 23, tratei de desativar a opção de “Reinicializar automaticamente ao fechar o Instalador” — pois eu queria me certificar de que todos os meus arquivos estavam no Pendrive, antes de encerrar a sessão Live.

  • Em sessões Live, sempre uso um Pendrive, com arquivos úteis — e salvo nele as Capturas de tela e anotações da instalação. — No caso do MX Linux, espero que tudo seja preservado na pasta /home da instalação final (de fato, foi), mas prudência e canja de galinha não fazem mal a ninguém.

Observe que, durante todo o processo, é possível alternar entre as abas de “Ajuda” e de “Live Log”, do lado esquerdo. — A experiência já me mostrou o quanto é fundamental focar na “Ajuda”, e ler todas as dicas com muita atenção. — Em caso de dúvida, leia o FAQ, o Manual do Usuário, a Wiki, os Vídeos, pesquise / peça ajuda no Forum, tudo isso a um clique da tela de Boas-Vindas (MX Wellcome).

O FAQ e o Manual também estão no canto superior esquerdo da Área de Trabalho, ao lado do ícone do Instalador — como se vê na imagem abaixo:

Recursos de Ajuda na tela de Boas-Vindas da sessão Live MX Linux

O MX Linux oferece uma enorme quantidade de recursos que não são comuns em outras distros — e muitas vezes, as dicas curtas não deixam claro o significado de cada um deles, para quem ainda não os conhece por experiência própria.

Teste da instalação

Autorização de montagem de outras partições pelo Usuário, no MX Tweak

Logo após instalar o MX Linux 23 (sem partição /home separada), testei se estava funcionando bem. — Para isso, configurei só algumas coisas básicas.

Uma das principais configurações que testei, foi autorizar a montagem de partições adicionais (as que não são do MX) pelo Usuário comum — pois a exigência de senha impediria a montagem automática no início da sessão Plasma KDE.

Montagem de partições pelo Dolphin: arquivos vão sempre para “Warehouse”

Uma vez dada essa autorização, basta clicar nas partições do lado esquerdo do Dolphin, para montar pelo uDisks2 — e posso habilitar a montagem automática das partições adicionais pelo KDE System settings >> Hardware >> Removable storage >> Removable devices (deixando o fstab só para as partições do sistema).

Isso é necessário, para que os aplicativos usem uma única partição (Warehouse) — pois não faz sentido espalhar documentos nas /home de 12 distros.

Aprovada a instalação — e habilitada a montagem sem privilégios — eu já podia “movê-la” para a partição definitiva, substituindo o MX-21.

Substituição do MX Linux 21

Substituição do MX-21 pelo MX Linux 23, no GParted

Pelo GParted do Mageia, “copiei” a partição provisória “rootMX23” (29,3 GiB) e “colei” na partição definitiva “Linux12” (30 GiB), do antigo MX-21. — O GParted expande a partição “colada”, para ocupar o espaço maior.

Diferenciando rótulo e UUID das 2 partições

Mudei o rótulo (Label) da cópia para “Linux12” — para atender às configurações das outras 11 distros — e alterei o identificador UUID da “partição provisória”, para que o Grub não as confunda, e não monte ambas no boot.

Linhas da /home e do Swap copiadas do fstab da instalação anterior

Copiei as linhas de /home e Swap do fstab do MX-21 e colei no fstab do MX Linux 23. — Assim, no próximo boot o MX-23 já vai usar a /home antiga.

Devolução da prioridade de boot do EFI e atualização do Grub do Mageia

Durante a instalação, o MX Linux 23 assumiu a prioridade de boot na configuração da UEFI Bios — Pelo comando efibootmgr, devolvi a prioridade de boot para o openSUSE (cujo Grub é meu Menu de inicialização); e atualizei também o meu Grub de reserva (Mageia).

# efibootmgr
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0007,0000,0003,000A,0002,0005,000E,0004,0006,000B,000F,0001,0010,0011
Boot0000* opensuse      HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\OPENSUSE\GRUBX64.EFI)
Boot0001* debian        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\DEBIAN\SHIMX64.EFI)
Boot0002* Fedora        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\FEDORA\SHIM.EFI)0000424f
Boot0003* mageia        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\MAGEIA\GRUBX64.EFI)
Boot0004* pclinuxos     HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\PCLINUXOS\GRUBX64.EFI)
(...)

# efibootmgr -o 0000,0003,000A,0002,0005,000E,0004,0006,000B,000F,0001,0010,0011,0007
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0000,0003,000A,0002,0005,000E,0004,0006,000B,000F,0001,0010,0011,0007
Boot0000* opensuse      HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\OPENSUSE\GRUBX64.EFI)
Boot0001* debian        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\DEBIAN\SHIMX64.EFI)
Boot0002* Fedora        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\FEDORA\SHIM.EFI)0000424f
Boot0003* mageia        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\MAGEIA\GRUBX64.EFI)
(...)

Grub do openSUSE, agora com dois MX Linux 23, em sda e sdb

Depois, entrei no openSUSE e atualizei seu Grub, que voltou a ser o “principal”.

  • A atualização do Grub do Mageia levou 3’11’’ (23:05:47 a 23:08:58);
    A atualização do Grub do openSUSE levou 31’’ (23:20:01 a 23:20:32);
    A atualização do Grub do MX Linux levou 2’01’’ (13:10:40 a 13:12:41), ainda com os-prober.

Pós-instalação

Início do MX-23 com as configurações da /home do MX-21

Com a partição /home “herdada” do MX-21, o MX-23 já iniciou com o antigo papel-de-parede, 2 instâncias do Conky, widgets Moon Phase  e Weather — e inúmeras configurações, que não eu precisaria repetir. — Faltavam poucas coisas.

Instalei os pacotes aha, html2text, screenfetch, usados pelo 2º Conky — e criei os agendamentos de registro (RAM, Versões dos softwares) e de limpeza do cache:

$ 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

Tempo de boot e uso inicial de RAM do MX Linux 23 KDE

Ao reiniciar, o boot do MX Linux levou 22’’, até a exibição do Painel do KDE Plasma (acima, à esquerda) — a mesma média registrada pelo MX-21 em Junho.

Aos 10 minutos uptime (iddle), o script RAM.sh registrou uso de 1197 MiB (praticamente o mesmo da captura, acima, à direita). — Isso era 27% mais do que os 940 MiB registrados pelo MX-21 em Junho — ou quase 24% a mais do que a média de 967 MiB nas 6 medidas anteriores.

Baixei e instalei o Google Chrome e o GoogleEarth. — Os repositórios do Google foram adicionados automaticamente, no processo:

$ history

  456  2023-08-01_00-12-59 date; sudo apt install ~/Downloads/google-chrome-stable_current_amd64.deb; date
  458  2023-08-01_00-19-38 wget https://dl.google.com/dl/earth/client/current/google-earth-stable_current_amd64.deb -O google-earth-stable.deb
  459  2023-08-01_00-21-04 date; sudo dpkg -i google-earth-stable.deb; date

Deletando a “partição provisória” pelo KDE Partition Manager

Pelo KDE Partition Manager, deletei a “partição provisória” — que não tinha mais utilidade, agora que a cópia na partição definitiva já foi testada e aprovada.

Alterei os repositórios para espelhos mais rápidos, pelo MX Repo Manager.

Configurei o KWrite para sempre exibir a numeração das linhas — pois nas versões mais novas do KDE a tecla F11 conflita com o atalho global — e configurei a tecla F10 para alternar “Dynamic Word Wrap” (on / off).

  • No MX-21, o Kate (20.12.2) e o KWrite ainda tinham esses atalhos (F10, F11) — mas no MX Linux 23, o Kate e KWrite (22.12.3) vêm sem eles.

Emparelhamento do celular pelo KDE Connect

Autorizei as portas para o KDE Connect, solicitei emparelhamento pelo celular, aceitei no MX Linux — e baixei as fotos da instalação.

Removendo o PackageKit (e o Plasma Discover)

Apareceu mais um aviso de atualizações na bandeja do sistema, e lembrei de remover o PackageKit — o que leva embora também o Plasma Discover (não uso).

Com isso, elimino avisos chatos (atualizo minhas distros 1 vez por semana, aos Domingos) — e “nivelo” o comportamento de todas elas — pois no Arch, no Void, no Slackware, por exemplo, não tenho PackageKit verificando atualizações (e elevando o uso de recursos). A “comparação” torna-se mais objetiva.

O PackageKit usa o gerenciador de pacotes de cada distro (apt, zypper, dnf) — em parceria com o Plasma Discover, no caso do KDE (ou outras Lojinhas, em outros DEs). — A utilidade dessa dupla dinâmica é fazer com que pareça simples o gerenciamento de todo tipo de pacotes, inclusive Snaps e Flatpaks (que têm seus próprios gerenciadores).

Nas distros de base Debian, também costumo remover o unattended-upgrades, que faz “atualizações de segurança”, sem perguntar, nem avisar — e registra em um log separado, o que dificulta meu acompanhamento do que acontece. — Esse pacote não veio no MX Linux 23.

Verificação da conexão e dos espelhos (Mirrors), num dia de Domingo

Em lugar disso tudo, executo um apt update, para ver se a conexão e os espelhos (Mirrors) estão Ok — caso contrário, não avanço — e um apt list --upgradable para ver o que será atualizado.

Depois, uso o Synaptic para “aplicar” essas atualizações — após examinar as seções “Obsoleto”, “Auto-Removível”, “Configurações Residuais” etc.

Pesquisa no Histórico do Synaptic

O Synaptic também é muito prático para pesquisar, instalar, remover pacotes — e seu Histórico permite pesquisar exatamente quando cada pacote foi instalado, removido ou atualizado, ao longo do tempo. — Por isso, infelizmente não tenho usado o MX Package Installer (só o MX Repo Manager).

Instalando os pacotes que faltavam

Com ajuda da lista gerada pelo user-installed-packages, instalei os “7 pacotes” que ainda faltavam: — kruler, kstars, npm, speedtest-cli, tree, xsane, yt-dlp.

  • Seria mais simples e rápido fazer isso pelo próprio user-installed-packages — mas preferi o Synaptic, para manter o Histórico unificado. — Só ficaram fora do Histórico do Synaptic, a instalação inicial dele mesmo, e do gnome-screenshot (pelo apt, ainda na sessão Live); e mais tarde, a do Chrome e do GoogleEarth, pelos comandos apt e dpkg.

A instalação do npm envolveu 357 pacotes — o que elevou o total de pacotes instalados, de 2415 para 2793, ao final do que parecia ser, só, “instalar 7 pacotes”. — Mas são dependências pequenas, e o espaço ocupado em disco aumentou apenas 543 MiB (de 8,12 GiB para 8,65 GiB): média de 1,4 MiB, cada.

Ainda é muito menos do que os 3686 pacotes instalados no Debian testing — e mais perto dos 2967 instalados no KDE Neon, uma distro “buntu-based” enxuta.

  • Em Março 2020, a instalação do npm no Debian testing envolveu 285 pacotes — e em Abril 2020 a instalação do npm no KDE Neon envolveu apenas 70 pacotes.

Dica para desabilitar os-prober

Me confundi com alguns ajustes próprios do MX Linux 23, quando tentei desativar o os-prober. — Pedi ajuda no Fórum, e logo recebi a dica: — Anular aquelas 3 linhas em /etc/default/grub, que remetem a /etc/default/grub.mx-defaults.

  • Depois disso, a atualização do Grub do MX Linux levou apenas 20’’, e no openSUSE levou apenas 26’’ — mas para isso também contribuiu a eliminação da outra cópia do MX-23 na “partição provisória”, pois o tempo é proporcional ao número de distros, e ao tamanho dos arquivos /boot/grub/grub.cfg dentro delas. — Por isso, não faz sentido que todas produzam arquivos enormes. — De qualquer modo, o Grub do openSUSE Tumbleweed é o único que consegue carregar todas as outras; e o do Mageia é o único que consegue detectar corretamente o openSUSE, instalado em partição BtrFS (sem partição /boot separada).

Editando /etc/hosts e /etc/hostname no MX Linux 23

Substituí “mx” por “Linux12” nos arquivos hosts e hostname.

  • Isso não pôde ser feito pelo comando $ sudo nano. — Tive de usar o su e executar # nano. — Foi bom ter habilitado a conta Root.

Configurando apt / Synaptic para deletar pacotes baixados, depois de instalados

Finalmente, lembrei de configurar o apt para deletar os pacotes baixados, depois de serem instalados. — Fiz isso pelo Synaptic >> Settings >> Preferences >> Files — e aproveitei para clicar no botão “Delete Cached Package Files”.

Ainda não tinha acumulado muita coisa em /var/cache/apt/archives — e o espaço ocupado em disco caiu apenas de 8,65 GiB para 8,48 GiB — mas esse cache nunca teve utilidade para mim.

Substituição do Weather pelo Weather2

Removi o antigo Weather widget (1) — que ainda funcionava em versões antigas do KDE Plasma — e instalei o Weather widget-2.

Instalação e teste do corona-cli

Pelo comando “sudo npm i -g corona-cli@latest”, instalei o corona-cli.

Desabilitando “Hide docks”, para o Gimp exibir o Toolbox

Instalar uma distro Linux nunca é uma experiência completa, se a gente não deparar com pelo menos 1 problema. — O Gimp 2.10.34 abriu sempre sem o Toolbox, e eu tinha de abri-lo manualmente, todas as vezes (2 cliques!). — Além disso o Toolbox também não minimizava, ao minimizar o Gimp.

Depois de alguns dias, acabei encontrando a solução: — Desabilitar a opção “Hide docks”, no submenu “Janelas”.

Integração de tema GTK-KDE com o pacote libreoffice-kf5

Ainda me incomodava a interface do LibreOffice, com menus em letrinhas miúdas e finas sobre fundo “cinzento-pré-INPS”. — Comentei com os amigos, e recebi a dica de instalar o pacote libreoffice-kf5, de integração de tema GTK-KDE.

___________________
• Publicado em 31 Julho 2023 e desenvolvido até 6 Agosto 2023.

— … ≠ “•” ≠ … —

MX Linux

PC desktop UEFI / GPT

quarta-feira, 5 de julho de 2023

Upgrade do Mageia 8 para Cauldron (Mageia9)

Detalhes do Mageia Cauldron (Mageia9) no Conky e no KInfocentre do Plasma KDE
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 dnfdo 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