Priorytety APT: gdy pakiet jest i w dystrybucji, i w repozytorium zewnętrznym

Zakres testu: co sprawdziliśmy na Debianie 12 z repozytorium Sury, a czego nie

Wydruki dokumentują historyczny eksperyment z 11 września 2026 na jednorazowej maszynie testowej z Debianem 12, na której obok archiwum dystrybucji skonfigurowano zewnętrzne repozytorium PHP. Nie są opisem bieżącej konfiguracji labu.

Kontrola wykonana 18 września 2026 na aktualnej VM deb12 z bm-lab-01 nie znalazła źródła Sury: kandydatami dla php8.2-cli i php8.2-redis były wersje z Debiana. Zachowany niżej zapis eksperymentu pokazuje mechanizm APT, lecz wersje pakietów i źródła trzeba zawsze sprawdzić na własnej, celowo przygotowanej VM przed wyciągnięciem wniosków dla produkcji.

Czego nie sprawdzaliśmy: zachowania przy trzech i więcej repozytoriach zewnętrznych naraz, reguł po zmianie wydania dystrybucji ani eksperymentu Sury na Ubuntu. Nazwy archiwów i dostępne pakiety trzeba tam sprawdzić osobno.

Jeden pakiet PHP z trzech źródeł w wyniku apt-cache policy

Zacznijmy od tego, co widać po dodaniu repozytorium zewnętrznego. Polecenie apt-cache policy pokazuje wszystkie znane wersje pakietu razem ze źródłem i priorytetem:

$ apt-cache policy php8.2-cli
php8.2-cli:
  Installed: 8.2.33-1+0~20260730.92+debian12~1.gbp655644
  Candidate: 8.2.33-1+0~20260730.92+debian12~1.gbp655644
  Version table:
 *** 8.2.33-1+0~20260730.92+debian12~1.gbp655644 500
        500 https://packages.sury.org/php bookworm/main amd64 Packages
        100 /var/lib/dpkg/status
     8.2.33-1~deb12u1 500
        500 .../debian-security.list bookworm-security/main amd64 Packages
     8.2.32-1~deb12u1 500
        500 .../debian.list bookworm/main amd64 Packages

Ten wydruk warto umieć czytać, bo zawiera komplet informacji potrzebnych do zrozumienia decyzji APT:

• Installed - wersja obecnie zainstalowana w systemie.
• Candidate - wersja, którą APT zainstaluje przy najbliższej okazji. To ona jest przedmiotem całego sporu.
• Gwiazdki *** - oznaczają wersję zainstalowaną.
• Liczba przy wersji - priorytet, z jakim ta wersja jest brana pod uwagę.
• Wpis /var/lib/dpkg/status z priorytetem 100 - to nie jest repozytorium, tylko sam fakt, że pakiet jest zainstalowany. Ten wpis pojawia się zawsze i odegra kluczową rolę w dalszej części artykułu.

Najważniejsza obserwacja: wszystkie trzy źródła mają priorytet 500. Repozytorium zewnętrzne nie jest w żaden sposób uprzywilejowane - dostało dokładnie tyle samo, co archiwum dystrybucji. A mimo to wygrywa.

Czym są priorytety APT i jak APT wybiera wersję do instalacji

Priorytet to liczba całkowita przypisana wersji pakietu. APT wybiera kandydata według prostej reguły: bierze wersję o najwyższym priorytecie, a przy remisie - najwyższą wersję. Pełna skala wygląda tak:

Dwa progi z tej tabeli decydują o wszystkim, co dzieje się dalej. Sto to priorytet wersji zainstalowanej - dlatego pakiet, który już jest w systemie, nie znika tak łatwo. Priorytet co najmniej tysiąc pozwala APT cofnąć wersję; przy wartości poniżej 1000 obniżenie nie nastąpi nawet wtedy, gdy wskazane źródło ma wyższy priorytet.

Przy równych priorytetach APT wybiera najwyższą wersję

Skoro wszystkie trzy źródła mają po 500, priorytet nie rozstrzyga niczego. APT przechodzi wtedy do drugiego kryterium i wybiera najwyższą wersję. Sprawdziliśmy to wprost, narzędziem, które porównuje wersje dokładnie tak jak APT:

$ dpkg --compare-versions \
    "8.2.33-1+0~20260730.92+debian12~1.gbp655644" gt "8.2.33-1~deb12u1" \
    && echo "zewnetrzna wyzsza"
zewnetrzna wyzsza

Wersja z repozytorium zewnętrznego jest wyższa od tej z bookworm-security, mimo że obie noszą numer 8.2.33. Różnica siedzi w części po myślniku - i nie jest przypadkowa.

Dlaczego wersja z repozytorium zewnętrznego wygrywa: tylda w numerze wersji Debiana

Porównywanie wersji w Debianie ma jedną regułę, która wygląda na drobiazg, a decyduje o całej sytuacji: znak tyldy sortuje się przed niczym, a znak plusa po niczym. Sprawdziliśmy to na prostych przykładach:

$ dpkg --compare-versions "1.0~rc1" lt "1.0"  && echo tak   # tak
$ dpkg --compare-versions "1.0"    lt "1.0+x" && echo tak   # tak
$ dpkg --compare-versions "1.0~x"  lt "1.0+x" && echo tak   # tak

Tylda istnieje po to, żeby oznaczać wersje przedpremierowe: 1.0~rc1 ma być niższe od 1.0, bo to kandydat wydany przed finalną wersją. Debian używa jej także w oznaczeniach poprawek dla stabilnego wydania - stąd 8.2.33-1~deb12u1.

Teraz zestawmy obie wersje obok siebie:

Wniosek dotyczy dokładnie tych historycznych wersji: przy równym priorytecie wygrała wersja Sury, bo jej pełny numer sortuje się wyżej. Nie jest to ogólna gwarancja ani deklaracja intencji każdego repozytorium zewnętrznego. Po dodaniu źródła zawsze sprawdź pełne wersje przez apt-cache policy.

Jak napisać regułę priorytetu w katalogu /etc/apt/preferences.d/

Reguły priorytetów zapisuje się w plikach w katalogu /etc/apt/preferences.d/. Wpis ma trzy pola:

Package: *                          # nazwa pakietu albo wzorzec
Pin: origin packages.sury.org       # czego dotyczy
Pin-Priority: 100                   # jaki priorytet nadac

Pole Pin ma kilka wariantów i wybór między nimi ma znaczenie praktyczne:

Wartości do tych pól nie trzeba zgadywać - podaje je samo apt-cache policy uruchomione bez nazwy pakietu:

$ apt-cache policy
 500 https://packages.sury.org/php bookworm/main amd64 Packages
     release o=deb.sury.org,a=bookworm,n=bookworm,c=main,b=amd64
     origin packages.sury.org
 500 .../debian.list bookworm/main amd64 Packages
     release v=12.15,o=Debian,a=oldstable,n=bookworm,l=Debian,c=main,b=amd64

W linii release widać wszystkie pola, po których można dopasowywać: o to pochodzenie, a archiwum, n nazwa wydania, l etykieta. Linia origin podaje nazwę serwera - i to jej używa zapis Pin: origin.

Pułapka: obniżenie priorytetu nie cofa pakietu już zainstalowanego

Tu zaczyna się część, która najczęściej zaskakuje. Załóżmy, że PHP przyszło już z repozytorium zewnętrznego i chcemy wrócić do wersji dystrybucyjnej. Zakładamy regułę obniżającą repozytorium zewnętrzne do priorytetu 100:

Package: *
Pin: origin packages.sury.org
Pin-Priority: 100

Wynik jest taki, jakby reguła nie istniała:

$ apt-cache policy php8.2-cli
  Installed: 8.2.33-1+0~20260730.92+debian12~1.gbp655644
  Candidate: 8.2.33-1+0~20260730.92+debian12~1.gbp655644    <- bez zmian
 *** 8.2.33-1+0~20260730.92+debian12~1.gbp655644 100
        100 https://packages.sury.org/php bookworm/main amd64 Packages
        100 /var/lib/dpkg/status
     8.2.33-1~deb12u1 500
        500 .../debian-security bookworm-security/main amd64 Packages

Wersja z dystrybucji ma teraz priorytet 500, a zewnętrzna tylko 100 - i mimo to kandydatem pozostaje ta zewnętrzna. W tym przypadku przejście na wersję dystrybucyjną byłoby obniżeniem wersji, a APT nie robi tego przy priorytecie poniżej 1000.

Można pomyśleć, że mocniejszy zapis pomoże. Sprawdziliśmy i priorytet ujemny:

Pin-Priority: -1

$ apt-cache policy php8.2-cli
  Candidate: 8.2.33-1+0~20260730.92+debian12~1.gbp655644    <- nadal bez zmian
 *** 8.2.33-1+0~20260730.92+debian12~1.gbp655644 100
         -1 https://packages.sury.org/php bookworm/main amd64 Packages
        100 /var/lib/dpkg/status

Zwróć uwagę na te dwie linie pod wersją. W tym historycznym przypadku repozytorium dostało -1, lecz wersja nadal miała 100 z wpisu /var/lib/dpkg/status, bo była zainstalowana. Ujemny pin nie odinstalowuje pakietu; kandydat zależy też od wersji zainstalowanej i pozostałych źródeł.

Obniżenie wersji pakietu wymaga priorytetu co najmniej 1000

Próg, który pozwala obniżyć wersję, to wartość co najmniej tysiąc. Zamiast obniżać repozytorium zewnętrzne, podnosimy archiwum dystrybucji:

Package: *
Pin: release o=Debian
Pin-Priority: 1001

Teraz kandydat faktycznie się zmienia:

$ apt-cache policy php8.2-cli
  Installed: 8.2.33-1+0~20260730.92+debian12~1.gbp655644
  Candidate: 8.2.33-1~deb12u1                              <- wersja z dystrybucji
     8.2.33-1~deb12u1 1001

Zanim jednak uznasz to za rozwiązanie, zobacz, co taka zmiana pociąga. Symulacja instalacji - która niczego nie zmienia w systemie - pokazuje skalę:

$ sudo apt-get -s install php8.2-cli
The following packages will be DOWNGRADED:
  ...
0 upgraded, 0 newly installed, 16 downgraded, 0 to remove and 0 not upgraded.

Jedno polecenie dotyczące jednego pakietu oznaczyło do obniżenia szesnaście pakietów. Tak wygląda w praktyce zależność między modułami PHP: pociągają się nawzajem i schodzą razem. Obniżanie wersji jest przy tym operacją ryzykowną: przejście w dół bywa nieobsługiwane przez skrypty instalacyjne i potrafi zostawić konfigurację w stanie pośrednim.

Wartość 1000 wystarcza technicznie; 1001 można przyjąć jako czytelny sygnał świadomego downgrade'u. W obu przypadkach jest to narzędzie do jednorazowej, zaplanowanej migracji, wykonywanej w oknie serwisowym i z kopią zapasową - nie stała polityka w pliku, o którym za pół roku nikt nie będzie pamiętał.

Pakiet dostępny tylko z repozytorium zewnętrznego

Dotąd mówiliśmy o pakiecie dostępnym z obu stron. Zupełnie inaczej wygląda sytuacja, gdy repozytorium zewnętrzne jest jedynym źródłem. Porównajmy dwa pakiety tym samym poleceniem:

$ apt-cache madison php8.2-cli
php8.2-cli | 8.2.33-1+0~20260730... | https://packages.sury.org/php bookworm/main
php8.2-cli | 8.2.33-1~deb12u1       | .../debian-security bookworm-security/main
php8.2-cli | 8.2.32-1~deb12u1       | .../debian.list bookworm/main

$ apt-cache madison php7.4-cli
php7.4-cli | 1:7.4.33-30+0~2026...  | https://packages.sury.org/php bookworm/main

PHP w wersji 8.2 to linia, którą Debian 12 niesie sam - stąd trzy wpisy. PHP 7.4 nie istnieje w archiwum tej dystrybucji w żadnej wersji; dostarcza go wyłącznie repozytorium zewnętrzne, stąd jeden wpis.

W tym eksperymencie blokada repozytorium zewnętrznego przy pakiecie z dwoma źródłami przełączyła kandydata na wersję dystrybucyjną, a przy pakiecie z jednym źródłem zostawiła brak kandydata. Wynik zależy od konkretnego pakietu, wersji zainstalowanej i aktualnego zestawu źródeł.

Widać to na pakiecie, którego w systemie jeszcze nie ma. Tak wygląda jego stan przed dodaniem reguły:

$ apt-cache policy php8.2-redis
  Installed: (none)
  Candidate: 6.3.0-2+0~20260711.69+debian12~1.gbpd148c3     <- z zewnatrz

Po założeniu reguły blokującej repozytorium zewnętrzne wynik wygląda tak:

$ apt-cache policy php8.2-redis
  Installed: (none)
  Candidate: 5.3.7+4.3.0-3                                  <- z dystrybucji
     6.3.0-2+0~20260711.69+debian12~1.gbpd148c3 -1
     5.3.7+4.3.0-3 500

Tu reguła zadziałała natychmiast i dokładnie tak, jak się spodziewamy - bo nie ma zainstalowanej wersji, która broniłaby pozycji. To jest ta sama reguła, która chwilę wcześniej nie zrobiła nic; różnica leży wyłącznie w tym, czy pakiet był już w systemie.

Gdyby ten sam zapis objął php7.4-cli, efektem nie byłoby przełączenie na starszą wersję, tylko komunikat o braku kandydata do instalacji.

Kolejność reguł w plikach preferences sprawdzamy na docelowej wersji APT

Podręcznik apt_preferences(5) z Debiana 12 (apt 2.6.1) nazywa reguły specific form i general form, lecz tych etykiet nie wolno używać jako skrótu do przewidywania wyniku. Rozstrzyga zachowanie konkretnej wersji APT oraz dokładna kolejność wpisów.

W izolowanym teście bez zmiany konfiguracji na obecnych maszynach naszego labu (APT 2.2, 2.4, 2.6, 2.8, 3.0 i 3.2) dwa pasujące wpisy Package: * z Pin: release * dały priorytet z pierwszego wpisu. Gdy najpierw był priorytet 101, wynik wynosił 101; po odwróceniu wpisów wynosił 999. Ten sam wynik uzyskaliśmy dla konkretnego pakietu. Nie zakładaj więc, że późniejszy, wyższy priorytet nadpisze wcześniejszą szeroką regułę.

Pliki w /etc/apt/preferences.d/ są czytane alfabetycznie, a wpisy w pliku od góry. Kolejność jest zatem częścią konfiguracji, ale sama nazwa 00-... nie zastępuje sprawdzenia wyniku. Ostateczną odpowiedź dają apt-cache policy NAZWA_PAKIETU i symulacja apt-get -s na pakiecie, którego politykę rzeczywiście zmieniasz.

Poniższa reguła jest prostym przykładem blokady jednego pakietu:

# /etc/apt/preferences.d/00-bez-automatycznych-aktualizacji.pref
Package: unattended-upgrades
Pin: release *
Pin-Priority: -1

Efekt jest całkowity - pakiet przestaje istnieć z punktu widzenia APT:

$ apt-cache policy unattended-upgrades
  Installed: (none)
  Candidate: (none)
     2.9.1+nmu3 -1
        500 .../debian.list bookworm/main amd64 Packages

$ sudo apt-get install unattended-upgrades
E: Package 'unattended-upgrades' has no installation candidate

Zwróć uwagę na dwie rzeczy. Po pierwsze, blokada działa nawet przy jawnym poleceniu instalacji - to nie jest tylko preferencja, to odcięcie. Po drugie, numer na początku nazwy ułatwia utrzymanie porządku, ale po każdej zmianie trzeba sprawdzić, czy nie pojawiła się konkurująca reguła i jaki kandydat faktycznie wynika z całego zestawu preferencji.

Ta reguła pokazuje przy okazji, dlaczego użyto tu priorytetu, a nie zamrożenia wersji. Zamrożenie działa na pakiet już zainstalowany - nie zapobiega instalacji czegoś, czego jeszcze nie ma. Priorytet ujemny blokuje instalację w ogóle, także wtedy, gdy pakiet miałby wejść jako zależność miękka czegoś innego. Więcej o tym rozróżnieniu piszemy w artykule o testowaniu aktualizacji.

Weryfikacja reguł priorytetów przez apt-cache policy

Reguły priorytetów mają nieprzyjemną właściwość: błędnie napisana reguła nie zgłasza błędu. Po prostu nie dopasowuje niczego, a system zachowuje się tak, jakby jej nie było. Dlatego każdą zmianę sprawdzamy trzema poleceniami.

1. Co APT uważa za kandydata - jedyne pytanie, które naprawdę się liczy:

apt-cache policy NAZWA_PAKIETU

2. Skąd pochodzą wszystkie znane wersje - przydatne, gdy chcesz zobaczyć, czy pakiet ma jedno źródło, czy kilka:

apt-cache madison NAZWA_PAKIETU

3. Co się faktycznie wydarzy - bez wykonywania zmiany. To jest krok, który wyłapuje niespodzianki w rodzaju szesnastu pakietów do obniżenia:

sudo apt-get -s install NAZWA_PAKIETU

Do tego jedno polecenie, które wypisuje, jak APT rozumie Twoje reguły - przydatne przy podejrzeniu, że wpis nie dopasowuje:

apt-cache policy | head -30

Sprawdzać trzeba na maszynie takiej samej jak docelowa. Te same reguły na Debianie i na Ubuntu dopasowują inaczej, bo nazwy archiwów i pola pochodzenia są inne - zapis działający na jednym systemie potrafi po cichu nie dopasować niczego na drugim.

Checklista po dodaniu repozytorium zewnętrznego do Debiana

1. Po dodaniu repozytorium zewnętrznego sprawdziłeś, ile pakietów przeszło pod jego opiekę, a nie tylko ten jeden, dla którego je dodawałeś.
2. Wiesz, że od tego momentu poprawki bezpieczeństwa dla tych pakietów przychodzą od opiekuna repozytorium, nie od zespołu dystrybucji.
3. Reguły priorytetów zakładasz przed instalacją pakietu, nie po - po instalacji najczęściej nie zmienią nic.
4. Ustaliłeś kolejność konkurujących reguł i potwierdziłeś wynik na docelowej wersji APT; nie zakładasz, że późniejszy wyższy priorytet sam nadpisze wcześniejszy wpis.
5. Wartości do pól Pin wziąłeś z apt-cache policy, a nie z pamięci - nazwa serwera i pole pochodzenia to dwie różne rzeczy.
6. Każdą regułę zweryfikowałeś przez apt-cache policy na pakiecie, którego dotyczy.
7. Przed zastosowaniem uruchomiłeś symulację i przeczytałeś, ile pakietów zostanie ruszonych.
8. Priorytet co najmniej tysiąc stosujesz świadomie, w oknie serwisowym, a nie jako stałą politykę.
9. Wiesz, które pakiety mają tylko jedno źródło - dla nich blokada oznacza brak możliwości instalacji, a nie przełączenie.
10. Reguły sprawdziłeś na systemie takim samym jak docelowy.

Repozytoria zewnętrzne są narzędziem, bez którego wielu aplikacji po prostu nie da się utrzymać - i nie ma powodu ich unikać. Warto tylko pamiętać, że dodanie takiego źródła to nie jest rozszerzenie wyboru, tylko zmiana tego, kto wydaje pakiety na Twoim serwerze. Priorytety są mechanizmem, który pozwala tę decyzję świadomie kształtować, zamiast przyjmować ją jako skutek uboczny jednej linijki w konfiguracji.