En av de mest kjente funksjonene i Debian er evnen til å oppgradere et installert system fra en stabil utgave til den neste: dist-upgrade - en velkjent frase - har i stor grad bidratt til prosjektets omdømme. Med noen forholdsregler, kan det å oppgradere en datamaskin ta så lite som et par minutter, eller noen få dusin minutter, avhengig av nedlastingshastigheten til pakkebrønnene.
6.7.1. Anbefalt prosedyre
Siden Debian har litt tid for å utvikle seg i perioden mellom stabile versjoner, bør du lese produktmerknadene før du oppgraderer.
In this section, we will focus on upgrading a Buster system to Bullseye. This is a major operation on a system; as such, it is never 100% risk-free, and should not be attempted before all important data has been backed up.
Another good habit which makes the upgrade easier (and shorter) is to tidy your installed packages and keep only the ones that are really needed. Helpful tools to do that include
aptitude
,
deborphan
,
debfoster
, and
apt-show-versions
(see
Seksjon 6.2.7, «Å finne installerte pakker automatisk»). For example, you can use the following command, and then use
aptitude
's interactive mode to double check and fine-tune the scheduled removals:
#
deborphan | xargs aptitude --schedule-only remove
Now for the upgrading itself. First, you need to change the
/etc/apt/sources.list
file to tell APT to get its packages from
Bullseye instead of
Buster. If the file only contains references to
Stable rather than explicit codenames, the change isn't even required, since
Stable always refers to the latest released version of Debian. In both cases, the database of available packages must be refreshed with the
apt update
command or the refresh button in
synaptic
(
Seksjon 6.2.1, «Initialisering»).
Once these new package sources are registered, you should first do a minimal upgrade with
apt upgrade
et al. as described in
Seksjon 6.2.3, «Oppgradering av systemet». By doing the upgrade in two steps, we ease the job of the package management tools and often ensure that we have the latest versions of those, which might have accumulated bugfixes and improvements required to complete the full distribution upgrade.
Once this first upgrade is done, it is time to handle the upgrade itself, either with
apt full-upgrade
,
aptitude
, or
synaptic
(
Seksjon 6.7, «Oppgradering fra en stabil distribusjon til den neste»). You should carefully check the suggested actions before applying them: you might want to add suggested packages or deselect packages which are only recommended and known not to be useful. In any case, the frontend should come up with a scenario ending in a coherent and up-to-date
Bullseye system. Then, all you need is to do is wait while the required packages are downloaded, answer the debconf questions and possibly those about locally modified configuration files, and sit back while APT does its magic.
6.7.2. Å håndtere problemer etter en oppgradering
Til tross for Debian vedlikeholderes beste innsats, går en større oppgradering ikke alltid så glatt som du kan ønske deg. Nye programvareversjoner kan være uforenlig med de foregående (for eksempel kan standardopptredene eller dataformatet deres ha endret seg). Dessuten kan noen bug slippe gjennom nåløyet til tross for testfasen som alltid går foran en Debian-utgivelse.
For å foregripe noen av disse problemene kan du installere apt-listchanges-pakken, som viser informasjon om mulige problemer ved begynnelsen av en pakkeoppgradering. Denne informasjonen er utarbeidet av pakkens vedlikeholder, og satt i /usr/share/doc/pakke/NEWS.Debian
-filer for å gjøre det enklere for brukerne. Å lese disse filene (eventuelt i apt-listchanges) bør hjelpe deg å unngå uønskede overraskelser.
You might sometimes find that the new version of a software doesn't work at all. This generally happens if the application isn't particularly popular and hasn't been tested enough; a last-minute update can also introduce regressions which are only found after the stable release. In both cases, the first thing to do is to have a look at the bug tracking system at
https://bugs.debian.org/package
, and check whether the problem has already been reported. If this is case, it will be also listed before the upgrade begins if you have
apt-listbugs installed. If it hasn't, you should report it yourself with
reportbug
. If it is already known, the bug report and the associated messages are usually an excellent source of information related to the bug:
i andre tilfeller kan brukere ha funnet en løsning på problemet, og delt sin innsikt om det i sine svar til rapporteringen;
I atter andre tilfeller, kan en fast pakke ha blitt utarbeidet og offentliggjort av vedlikeholderen.
Avhengig av hvor alvorlig feilen er, kan en ny versjon av pakken bli forberedt spesielt til en ny revisjon av «stable»-utgivelsen. Når dette skjer, blir den forbedrede pakken gjort tilgjengelig i
proposed-updates
-seksjonen i Debian-speilene (se
Seksjon 6.1.2.3, «Foreslåtte oppdateringer»). Den tilsvarende oppføring kan da midlertidig legges til
sources.list
-filen, og oppdaterte pakker kan installeres med
apt
eller
aptitude
.
Noen ganger er den forbedrede pakken ikke tilgjengelig i denne delen ennå, i påvente av en validering av Stable-utgivelsesadministratorne. Du kan kontrollere om det er tilfelle på deres nettside. Pakker oppført der er ikke tilgjengelige ennå, men da vet du i det minste at publiseringsprosessen pågår.
6.7.3. Opprydding etter en oppgradering
APT sikrer vanligvis en ren oppgradering, trekker inn nye og oppdaterte avhengigheter eller fjerner motstridende pakker. Men selv å være et så flott verktøy, kan det ikke dekke alle oppgaver brukere og administratorer vil møte etter en oppgradering, fordi de krever en menneskelig beslutning.
6.7.3.1. Pakker fjernet fra Debian-arkivet
Sometimes the Debian ftpmasters remove packages from the Debian archive, because they contain release critical bugs, were abandoned by their upstream author or their package maintainer, or simply reached their end of life. In this case a newer Debian release does not ship the package anymore. To find all packages, which do not have a package source, use the apt-show-versions
command:
$
apt-show-versions | grep "No available version"
Et lignende resultat kan oppnås ved aptitude search ~o
. Hvis pakkene som blir funnet ikke er nødvendige lenger, bør de fjernes fra systemet, fordi de ikke lenger vil møte noen oppdateringer for kritiske eller sikkerhetsrelaterte feil lenger.
6.7.3.2. Dummy og overgangspakker
Noen ganger kan det være nødvendig for en pakke å få et nytt navn. I dette tilfellet holdes ofte den gamle pakken som en (nesten) tom pakke, avhengig av den nye og installerer bare de obligatoriske filene i
/usr/share/doc/package/
. Slike pakker kalles "dummy" eller "overgangs"-pakker. Hvis pakkens vedlikeholder også endret delen av denne pakken til
oldlibs
, deretter kan verktøy som
aptitude
,
deboprhan
, eller
debfoster
(se sidestolpe
ALTERNATIV deborphan
og debfoster
) hente disse pakkene for å foreslå fjerning.
Dessverre er det for tiden ingen idiotsikker måte å sørge for at disse pakkene automatisk fjernes eller plukkes av verktøyene nevnt ovenfor. En måte å sjekke om systemet fortsatt har noen av disse pakkene installert, er å se gjennom pakkebeskrivelsene til installerte pakker og deretter sjekke resultatene. Vær forsiktig så du ikke planlegger resultatene for automatisk fjerning, fordi denne metoden kan føre til falske positiver:
$
dpkg -l | grep ^ii | grep -i -E "(transition|dummy)"
6.7.3.3. Gamle eller ubrukte oppsettfiler
If the upgrade was successful there might be some configuration file cruft, either from dpkg (see
Seksjon 5.2.3, «Sjekksummer, Liste med oppsettfiler, med mere»), ucf or from removed packages. The latter can be
purged by using
apt autoremove --purge
. The configuration files that were handled by
dpkg or
ucf during the upgrade process have left some counterparts with a dedicated suffix, e.g.
.dpkg-dist
,
.dpkg-old
,
.ucf-old
. Using the
find
or
locate
command can help to track them down. If they are no longer of any use, they can be deleted.
6.7.3.4. Filer som ikke hører hjemme i noen pakke
Debian-retningslinjene håndhever at pakker ikke etterlater filer når de blir renset. Brudd på dette prinsippet er en alvorlig feil, og du vil sjelden støte på det. Hvis du gjør det, rapporter det; og hvis du er nysgjerrig skjønt, kan du bruke cruft eller cruft-ng pakken for å sjekke systemet for filer som ikke hører hjemme i noen pakke.