Como executar com segurança grandes atualizações de pacotes no Debian Unstable?

Question

Eu tenho usado o Debian Unstable (sid) por alguns meses. O único problema sério que tive foi o Python3 quebrar temporariamente durante uma atualização, e felizmente consegui consertá-lo em um dia, uma vez que os mantenedores liberaram uma correção.

No entanto, estou tentando evitar tais dores de cabeça no futuro, e estou aqui para perguntar sobre as melhores práticas para determinar quando ir em frente com atualizações de pacotes na instável Debian e quando esperar até que os bugs sejam corrigidos antes de atualizar. Ou seja: como posso manter um sistema instável atualizado do Debian, evitando tanto risco quanto possível de quebrar coisas durante a instalação?

Por exemplo, neste momento, a execução de sudo apt-get update; sudo apt-get dist-upgrade mostra mais de 200 pacotes que precisam de atualização e 2 sugere a remoção:

The following packages were automatically installed and are no longer required:
  libnfs8 python-subprocess32
Use 'sudo apt autoremove' to remove them.
The following NEW packages will be installed:
  libnfs11 libzstd1 python-kiwisolver python-olefile
The following packages will be upgraded:
  apt apt-utils atom-beta base-passwd binutils binutils-common binutils-x86-64-linux-gnu bluetooth bluez bubblewrap
  ca-certificates ca-certificates-java console-setup console-setup-linux cpp cpp-7 dconf-gsettings-backend
  dconf-service e2fslibs e2fsprogs e2fsprogs-l10n evince evince-common fontconfig fontconfig-config g++ g++-7 gcc
  gcc-7 gcc-7-base gcc-8-base geany geany-common gir1.2-glib-2.0 gnome-desktop3-data gtk-update-icon-cache gvfs
  gvfs-bin gvfs-common gvfs-daemons gvfs-libs keyboard-configuration libapt-inst2.0 libapt-pkg-perl libapt-pkg5.0
  libarpack2 libasan4 libatomic1 libavcodec57 libavformat57 libavresample3 libavutil55 libbabl-0.1-0 libbinutils
  libbluetooth3 libboost-atomic1.62.0 libboost-chrono1.62.0 libboost-date-time1.62.0 libboost-filesystem1.62.0
  libboost-iostreams1.62.0 libboost-locale1.62.0 libboost-program-options1.62.0 libboost-python1.62.0
  libboost-regex1.62.0 libboost-system1.62.0 libboost-thread1.62.0 libcairo-gobject2 libcairo2 libcc1-0 libcilkrts5
  libcom-err2 libcomerr2 libcups2 libcupsfilters1 libcupsimage2 libdconf1 libdouble-conversion1 libdw1 libelf1
  libevdocument3-4 libevview3-3 libext2fs2 libfftw3-double3 libfontconfig1 libgcc-7-dev libgcc1 libgegl-0.3-0
  libgfortran4 libgirepository-1.0-1 libglib2.0-0 libglib2.0-bin libglib2.0-data libgnome-desktop-3-17 libgomp1
  libgpg-error0 libgtk-3-0 libgtk-3-bin libgtk-3-common libharfbuzz-icu0 libharfbuzz0b libhdf5-100
  libhttp-negotiate-perl libidn11 libinput-bin libinput10 libitm1 libjs-sphinxdoc libkpathsea6 liblsan0 liblz4-1
  libmpx2 libnm0 libnspr4 libnss3 libopenmpt-modplug1 libopenmpt0 libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0
  libparted-fs-resize0 libparted2 libperl5.26 libpostproc54 libprocps6 libpython-stdlib libpython2.7
  libpython2.7-minimal libpython2.7-stdlib libpython3-dev libpython3-stdlib libqt4-dbus libqt4-declarative
  libqt4-designer libqt4-dev libqt4-dev-bin libqt4-help libqt4-network libqt4-opengl libqt4-opengl-dev
  libqt4-qt3support libqt4-script libqt4-scripttools libqt4-sql libqt4-sql-mysql libqt4-sql-sqlite libqt4-svg
  libqt4-test libqt4-xml libqt4-xmlpatterns libqt5core5a libqt5dbus5 libqt5gui5 libqt5multimedia5 libqt5network5
  libqt5opengl5 libqt5printsupport5 libqt5svg5 libqt5widgets5 libqt5x11extras5 libqtcore4 libqtdbus4 libqtgui4
  libquadmath0 libservlet3.1-java libsoup-gnome2.4-1 libsoup2.4-1 libsqlite3-0 libss2 libstdc++-7-dev libstdc++6
  libswresample2 libswscale4 libtiff5 libtsan0 libtumbler-1-0 libubsan0 libvlc-bin libvlc5 libvlccore9 libvolume-key1
  libvte-2.91-0 libvte-2.91-common libwww-robotrules-perl libxft2 ndiff network-manager nmap nmap-common parted perl
  perl-base perl-modules-5.26 procps python python-apt-common python-matplotlib python-matplotlib-data python-minimal
  python-pil python-tk python-tz python2.7 python2.7-minimal python3 python3-apt python3-crypto python3-dev python3-gi
  python3-minimal qdbus qt4-designer qt4-linguist-tools qt4-qmake qt5-gtk-platformtheme qtcore4-l10n
  qttranslations5-l10n sqlite3 tumbler tumbler-common virtualbox virtualbox-dkms virtualbox-qt vlc vlc-bin
  vlc-plugin-base vlc-plugin-notify vlc-plugin-qt vlc-plugin-samba vlc-plugin-skins2 vlc-plugin-video-output
  vlc-plugin-video-splitter vlc-plugin-visualization xfce4-settings xserver-xorg-input-libinput
234 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 275 MB/275 MB of archives.
After this operation, 5,831 kB of additional disk space will be used.
Do you want to continue? [Y/n]

Como você determinaria se essas atualizações / remoções são ou não seguras (se houver algum bug conhecido que interrompa a instalação do pacote)?

Idealmente, não terei que ler centenas de páginas de relatórios de bugs toda vez que eu quiser fazer uma atualização, mas também não quero instalar todas elas cegamente sem saber se isso vai quebrar meu computador.

Você realmente verifica manualmente os relatórios de erros de cada pacote individual ou há uma maneira mais eficiente de fazer isso? Quando você está mantendo um sistema instável do Debian, quais as etapas que você toma durante as atualizações em todo o sistema para saber quando esperar pela atualização?

    

Answer 1

Eu sei que esta não é a resposta que você está procurando, mas acho que é a certa:

Você não faz. Você apenas usa o Debian estável para isso.

Se você quiser usar pacotes novos e atualizados, terá que conviver com os (raros) momentos de pacotes quebrados. Não há como os mantenedores de pacotes verificarem se uma de suas (muitas) dependências possui uma atualização que pode quebrar seu próprio pacote, já que eles teriam que examinar todos os changelogs e também executar testes, porque às vezes os changelogs não são precisos ou completos .

Como alternativa, você pode usar o debian stable e misturar alguns pacotes da unstable se realmente precisar de uma versão atualizada dele. Mas você ainda precisa verificar se as atualizações desses pacotes são compatíveis com seu sistema estável.

Você deve sempre poder reverter para versões anteriores de pacotes, desde que não limpe o cache. Você pode clonar sua máquina, tentar a atualização e, se os testes forem bem-sucedidos, você poderá fazer as atualizações na sua máquina principal.

Do you actually manually check the bug reports for each individual package, or is there a more efficient way of doing this? When you are maintaining a Debian unstable system, what steps do you take during system-wide updates like this to know when to hold off on updating?

Eu não uso instável para sistemas produtivos que precisam funcionar e não podem pagar por nenhum tempo de inatividade. Para os sistemas instáveis: eu cruzo meus dedos e atualizo. Se algo não funcionar como esperado, basta carregar meu último snapshot btrfs para reverter todo o meu sistema e esperar até que os problemas sejam corrigidos no upstream.

    

Answer 2

O

arochester forneceu uma ótima resposta, então não vou reiterar o que está lá.

Além disso, aqui estão algumas dicas para ajudar a descobrir o que provavelmente irá quebrar:

1. Sempre verifica se há relatos de erros nas novas versões do kernel, glibc e libstdc ++. Dependendo do seu sistema, você provavelmente pode adicionar qualquer biblioteca SSL que você usa, seu sistema init e possivelmente um punhado de outras bibliotecas para isso (por exemplo, bibliotecas Qt ou GTK se você tiver uma instalação de desktop). Se um desses componentes tiver um bug que o afete, é muito provável que, no mínimo, vá quebrar alguma coisa e possivelmente remover todo o sistema. Este conselho não é apenas para usuários do Debian, mas qualquer um usando uma distribuição como o Debian Sid.

2. Verificar o apt, dpkg e outros pacotes do gerenciador de pacotes também é uma boa idéia. Estes não são tão propensos a matar o seu sistema, mas a recuperação de um sistema quebrado por causa de um deles é bastante difícil (eu lembro claramente de ter recuperado manualmente alguns sistemas alguns anos atrás quando o gerenciador de pacotes do Gentoo tinha um bug que limpou a lista de pacotes instalados pelo usuário em uma atualização).

3. Como isso soa, certifique-se de reinicializar após a conclusão da atualização. A maioria dos problemas que vi em sistemas como esse surgiu de programas antigos sendo executados junto com os mais recentes.

4. Eu sugeriria usar o aptitude , se possível. Ele tem um modo de visualização incrível que permite que você veja por que cada novo pacote está sendo instalado, o que depende dos pacotes que estão sendo atualizados e por que os pacotes excluídos do upgrade estão sendo ignorados. Esta informação é inestimável para descobrir o que é provável que quebrar por causa de uma atualização. Obter essas mesmas informações de apt-get ou dpkg exige um monte de trabalho manual para rastrear as dependências.

Answer 3

As a longtime sid user, where the possibility of an update breaking the system is a daily risk, here's my daily routine.

1. In a root terminal with the GUI still running

apt update

apt full-upgrade -d

Now, stop and review carefully what is about to happen. First, look for removals. If anything is to be removed, that is your first and primary sign of danger. If it has been a long while (many days or weeks) since your last update, and you really want to get the system updated, then you need to research any package that is to be removed, using depends and rdepends and the information in Debian packages. Sometimes a package is obsoleted by introduction of a replacement package with a different name, so the prior package can safely be let go. But the more typical case is that a dependency will be broken by other upgraded packages, resulting in removal of something that you/your system needs, and that will break it. So, when you see removals, especially when your system has been updated in the recent past, it's safest and easiest to abort the full-upgrade with a "n", and try again tomorrow when it's (hopefully) safe.

2. If it looks safe to proceed, answer "y" and let the packages be downloaded.

3. Ctrl-Alt-F1 to the tty1 console, and log in as root.

systemctl isolate multi-user.target

Someone will soon post that this is not necessary. I'm not so sure. I'm not a software engineer and I don't wish to have any breakage in the xserver and GUI part of my systems. I have three fully updated sid systems that have been running error free since the last time some piece of hardware broke or got upgraded some years ago, so .....

4.

apt full-upgrade

apt clean

systemctl isolate graphical.target && exit

It has happened very rarely that, even with no packages removed, a buggy new package has broken sid systems. But this situation is pretty obvious and the fixed package comes in pretty quickly, so I doubt this would even happen in testing.

Fonte: link