kleiner Einwurf:
backports bekommen per default Priority 100
(== Priority der installierten Pakete, sprich des Release 'a=now', das ermöglicht upgrades)
Priority 1 ist das default-Priority des Repo experimental.
'-t ....-backports' hebt dieses Repo temporär auf die Priority 990.
guennid hat geschrieben:
Gibts das Paket nur in den Backports und ich will das installieren, dann reicht ein apt-get install paket aus.
Ich halte das für unzutreffend. Der neuere backports-Kern wird ohne explizite backports-Angabe nicht installiert.
Die Aussage stimmt aber.
linux-image-amd64 aus backports hat zwar höhere Version, jedoch niedrigere Priority.
Somit ohne '-t stretch-backports' oder 'linux-image-amd64/stretch-backports' keine Installation.
Falls guennid sich auf das meta bezieht (was aber kein kernel ist), hätte er Recht.
'.... install linux-image-4.14......-amd64', also das kernel-paket selbst installiert sich aber ohne spezielle Angabe,
da kein gleichnamiges im Standard-Repo existiert,
und wenn keine problematischen Abhängigkeiten dem entgegenstehen.
Im Umfeld des kernel gibt es gelegentlich initramfs-tools in mehreren Versionen (noch kniffliger wenn die kernel-headers hinzukommen), somit ist guennids Beispiel nicht als Gegenargument für die Aussage tauglich.
Nichtsdestotrotz halte ich ein '-t stretch-backports' für empfehlenswert.
'... dist-upgrade -t stretch-backports'
naja. Genausogut könnte backports auch mit Priority 500 betrieben werden.
Problematisch dabei: backports-Pakete sind für das Funktionieren in einer Standard-Installation gedacht/gebaut,
nicht unbedingt, um mit anderen backports-Paketen zu funktionieren.
Bsp. kernel <-> nvidia-...-dkms (was sich aber durch ein späteres backports Paketes des nvidia löste)