Actualizarea Debian începe cu verificarea arhitecturii

Înainte să stabiliți când actualizați o distribuție, verificați dacă sistemul poate trece la versiunea dorită. Debian 13 arată de ce contează această ordine: un calculator poate rula în continuare aplicația existentă fără să aibă o cale acceptată către versiunea următoare. Inventariați arhitectura instalată efectiv și nucleul cu care va porni sistemul înainte să estimați lucrarea ca pe o simplă actualizare de pachete.

Privit din noiembrie 2026, anunțul Debian 13 din 9 august 2025 fixează reperul istoric. Schimbările pentru i386 și armel au sensuri diferite. Formula „a fost eliminat suportul pe 32 de biți” ar ascunde tocmai informația de care administratorul are nevoie pentru a alege o cale.

Disponibilitatea pachetelor răspunde doar la o parte din întrebare

Notele versiunii trixie, consultate în noiembrie 2026, deosebesc rularea aplicațiilor i386 vechi pe amd64 de întreținerea unui sistem de operare i386. Nu există nucleu oficial sau program de instalare pentru i386. Unele pachete i386 rămân pentru compatibilitate, într-o selecție redusă și cu cerința SSE2. Debian recomandă să nu actualizați un sistem i386 la trixie, ci să reinstalați pe amd64 unde este posibil sau să retrageți echipamentul. Trecerea între arhitecturi fără reinstalare este descrisă drept posibilă, dar riscantă.

Aceste diferențe previn o concluzie înșelătoare: prezența unui pachet în arhivă nu dovedește că sistemul are o cale acceptată de instalare și pornire. O dependență a aplicației poate rămâne disponibilă pentru o altă utilizare a arhitecturii. Înregistrarea din arhivă răspunde la o întrebare mai restrânsă decât „poate acest server să continue cu noua versiune?”.

Capacitatea echipamentului și arhitectura instalată trebuie consemnate separat. Un procesor capabil să ruleze un sistem pe 64 de biți nu transformă o instalare existentă pe 32 de biți într-una pe 64 de biți. Planul migrării trebuie să descrie ce se va schimba efectiv pe disc și cum va fi restaurată aplicația. Prelungirea utilizării printr-un pachet de compatibilitate și înlocuirea sistemului de operare sunt decizii diferite.

Separarea este utilă mai ales când un server vechi a acumulat responsabilități nedocumentate. Înainte de reinstalare, identificați datele serviciului care trebuie păstrate, configurația de referință și modul în care alt calculator ar putea prelua aplicația. Sunt întrebări propuse pentru planificare, nu constatări despre vreun server AL+. Politica arhitecturilor oferă un motiv să le puneți înainte de intervalul de mentenanță.

armel cere o discuție diferită

Secțiunea armel din aceleași note descrie o actualizare condiționată, fără program de instalare și cu suport oficial al nucleului limitat la Raspberry Pi 1, Zero și Zero W. Pentru alte echipamente ar fi nevoie de un nucleu furnizat de un terț. Trixie este ultima versiune armel; Debian recomandă reinstalarea pe armhf sau arm64 unde este posibil, ori retragerea echipamentului.

Un nucleu furnizat de un terț aduce, așadar, o responsabilitate care trebuie numită explicit. Cineva trebuie să-i cunoască proveniența, modul de actualizare și compatibilitatea cu echipamentul. „Actualizarea se încheie” nu ar fi o dovadă suficientă pentru acceptarea lucrării dacă nucleul înlocuitor nu poate porni pe echipamentul instalat. În schimb, lipsa unui program de instalare nu dovedește singură că orice sistem armel existent este imposibil de actualizat.

Pentru o organizație mică, această diferență schimbă predarea. Un nucleu oficial acceptat și un nucleu întreținut separat pot lăsa aplicația neschimbată în ochii utilizatorului. Pentru persoana care o întreține, munca diferă când apare o corecție de securitate, o schimbare a stocării sau o problemă la pornire. Alegerea poate fi rezonabilă dacă acordul de mentenanță include această muncă.

Nu transformați numele unei arhitecturi într-o promisiune despre toate dispozitivele vândute sub o etichetă asemănătoare. Consemnați placa exactă și calea aleasă pentru nucleu. O arhitectură de înlocuire compatibilă cere și componente de aplicație compatibile; mutarea sistemului de operare nu dovedește că toate executabilele sau dependențele perifericelor au fost mutate odată cu el.

Păstrarea versiunii vechi poate fi o etapă de tranziție asumată

Obiecția cea mai puternică este practică: înlocuirea unei instalări funcționale poate produce mai multe perturbări decât păstrarea ei temporară. Aceasta poate fi o alegere bună de tranziție când versiunea existentă și pachetele relevante încă primesc suportul necesar organizației. Alegerea cere verificarea suportului la o dată precizată, un responsabil și o condiție de încheiere. Articolul nu certifică durata de suport rămasă pentru vreo instalare anume.

Etapa de tranziție devine fragilă când singura dovadă consemnată este „încă funcționează”. Funcționarea de astăzi spune puțin despre recuperarea după o defecțiune a echipamentului. O amânare utilă explică dependențele serviciului și evenimentul care va declanșa migrarea. Păstrează și informațiile necesare unei persoane care nu a participat la decizie.

Nici reinstalarea imediată nu este automat mai sigură. O schimbare grăbită a arhitecturii poate scoate la iveală pachete lipsă sau căi de date nedocumentate. Verificarea eligibilității vă ajută să alegeți între alternative bine delimitate înainte de a modifica serverul, în loc să descoperiți în timpul unei actualizări obișnuite că era necesar un alt proiect.

Scrieți decizia migrării înaintea procedurii de actualizare

O decizie utilă consemnează arhitectura instalată, capacitatea echipamentului, nucleul propus și instalarea de destinație. Precizează dacă lucrarea este o actualizare a distribuției pe instalarea existentă, o reinstalare cu restaurare sau o rămânere temporară pe o versiune mai veche. Dovezile privind recuperarea trebuie păstrate alături de această alegere, fiindcă instalarea cu succes a pachetelor este doar o parte din restabilirea serviciului.

Într-un proiect de dezvoltare software la comandă, acest inventar ar trebui să contribuie la stabilirea lucrărilor de mentenanță. Un serviciu nu poate promite o actualizare obișnuită de dependențe când sistemul de operare are nevoie de migrare între arhitecturi. Schimbările din august ale Debian fac vizibilă limita: stabiliți dacă destinația poate găzdui aplicația, apoi planificați actualizarea pachetelor care o aduce acolo.