Hallo Liste,
ich habe wegen einem Paket, welches "unbedingt" neuer sein musste backports.org in die sources.list eingetragen und das pinning von einer anderen Maschine übernommen:
bernd:~# cat /etc/apt/preferences Package: * Pin: release a=lenny Pin-Priority: 990 Package: * Pin: release a=lenny-proposed-updates Pin-Priority: 990 Package: * Pin: release a=lenny-backports Pin-Priority: 970 Package: * Pin: release a=packages.dotdeb.org Pin-Priority: 950 Package: * Pin: release a=testing Pin-Priority: 790 Package: * Pin: release a=unstable Pin-Priority: 590
Im Gegensatz zur Quelle dieser "preferences" meint der betroffene Server nun alles Mögliche aus den backports aktualisieren zu müssen. Was ist an meinem pinnig falsch (abgesehen davon, dass ich den "*" ja zum Paketnamen ändern könnte)?
Mit freundlichen Grüßen / With kind regards Ronny Seffner
Hi,
2011/3/29 Ronny Seffner ronny@seffner.de:
ich habe wegen einem Paket, welches "unbedingt" neuer sein musste backports.org in die sources.list eingetragen und das pinning von einer anderen Maschine übernommen:
nur ein Detail: es heißt inzwischen backports.debian.org, weil es ein offizieller Debian-Dienst ist.
Pin: release a=lenny-proposed-updates Pin-Priority: 990 Package: *
Hast du mal Pin-Priority: 500 probiert?
Viele Grüße, Torsten
Hallo Torsten,
Hast du mal Pin-Priority: 500 probiert?
Ja eben gerade, danach ein 'aptitude update' und das 'aptitude dist-upgrade' ist noch immer der Meinung mein halbes System umpopeln zu wollen ;-(
Mit freundlichen Grüßen / With kind regards Ronny Seffner
einmalig CCed, da die Diskussion schon einige Tage alt ist - bitte kein CC zurück an mich
Am Dienstag, den 29.03.2011, 19:37 +0200 schrieb Ronny Seffner:
ich habe wegen einem Paket, welches "unbedingt" neuer sein musste backports.org in die sources.list eingetragen und das pinning von einer anderen Maschine übernommen:
bernd:~# cat /etc/apt/preferences
[snip]
Im Gegensatz zur Quelle dieser "preferences" meint der betroffene Server nun alles Mögliche aus den backports aktualisieren zu müssen. Was ist an meinem pinnig falsch (abgesehen davon, dass ich den "*" ja zum Paketnamen ändern könnte)?
apt-cache policy
(ohne irgend ein weiteres Argument - du kannst das Ergebnis ja auch posten). Dann schau dir das Resultat an und prüfe, welche Quellen welche Priorität haben und ob deine "Pin:"-Zeilen auch richtig formuliert sind. Ich vermute mal, dass "a=lenny" auf gar nichts zutrifft und deine Lenny-Quellen daher auch keine Priorität von 990 haben. Das dürfte eher "a=oldstable" und/oder "n=lenny" sein.
MfG Daniel
Hallo Daniel,
das wird die richtige Richtung. Ein "n=lenny" an Stelle das "a=lenny" bewirkt laut 'apt-cache policy' nichts. "a=oldstable" allerdings löst mein Problem. Nur zufrieden bin ich damit nicht, aus zwei Gründen: - das Ganze passiert erst, wenn die backports mit in die sources.list kommen, weil deren PIN 970 funktioniert - ich will nicht mit jedem Release dran denken müssen apt umzupopeln, man muss doch einmal lenny festlegen und dann dabei bleiben können
Fangen wir doch anders an: - ich möchte backports verwenden, aber nur wenn ich das ausdrücklich bei der Installation eines Paketes angebe - ich möchte, dass installierte backports-Pakete bei upgrade/dist-upgrade mit aktualisiert werden - verwende ich die Pin-Priority 200 wie auf backports.org angegeben, werden auch andere Pakete auf backports aktualisiert, die ich gar nicht will - ich möchte nirgends mit stable/oldstable/testing usw. arbeiten, weil das morgen schon anders sein könnte
Mit freundlichen Grüßen / With kind regards Ronny Seffner
Am Montag, 4. April 2011, 15:04:31 schrieb Ronny Seffner:
Hallo Daniel,
das wird die richtige Richtung. Ein "n=lenny" an Stelle das "a=lenny" bewirkt laut 'apt-cache policy' nichts. "a=oldstable" allerdings löst mein Problem. Nur zufrieden bin ich damit nicht, aus zwei Gründen: - das Ganze passiert erst, wenn die backports mit in die sources.list kommen, weil deren PIN 970 funktioniert
- ich will nicht mit jedem Release dran denken müssen apt umzupopeln, man
muss doch einmal lenny festlegen und dann dabei bleiben können
Fangen wir doch anders an:
- ich möchte backports verwenden, aber nur wenn ich das ausdrücklich bei
der Installation eines Paketes angebe - ich möchte, dass installierte backports-Pakete bei upgrade/dist-upgrade mit aktualisiert werden - verwende ich die Pin-Priority 200 wie auf backports.org angegeben, werden auch andere Pakete auf backports aktualisiert, die ich gar nicht will - ich möchte nirgends mit stable/oldstable/testing usw. arbeiten, weil das morgen schon anders sein könnte
Mit freundlichen Grüßen / With kind regards Ronny Seffner
Wenn ich was wie z.B. apt-get -t lenny-backports install bacula angebe, wird IMHO das (und eigentlich auch minimal nur das) vom entsprechenden Eintrag in /etc/apt/sources.list besorgt.
Jetzt die Unklarheit meinerseits: Es müßte / sollte doch auch von dieser Quelle her aktuell gehalten werden, so daß pinning eigentlich überflüssig ist ... ???
Bernhard
Wie das im Fall dist-upgrade funtioniert, kann ich nur vermuten. Es hängt vermutlich davon ab, ob ich "Dauernamen" (stable) und | oder "Releasenamen" (woody) bei den entsprechenden Einträgen verwende.
Jetzt die Unklarheit meinerseits: Es müßte / sollte doch auch von dieser Quelle her aktuell gehalten werden, so daß pinning eigentlich überflüssig ist ... ???
Das hätte ich so auch erwartet, aber es gab mal einen Grund warum ich mit dem Pinning überhaupt angefangen habe und der lag entweder bei backports oder dotdeb und ich kann das jetzt alles nicht mehr nachvollziehen. Im Moment habe ich nur noch Pinning für backports an mit 200. Mal sehen, wie es sich verhält.
Mit freundlichen Grüßen / With kind regards Ronny Seffner
Am Montag, den 04.04.2011, 15:04 +0200 schrieb Ronny Seffner:
das wird die richtige Richtung. Ein "n=lenny" an Stelle das "a=lenny" bewirkt laut 'apt-cache policy' nichts.
Verstehe ich dann leider nicht, denn das funktioniert hier und ist so auch in `man apt_preferences' beschrieben.
Vielleicht hängst du deine sources.list, deine /etc/apt/preferences und /etc/apt/apt.conf mal an?
MfG Daniel
lug-dd@mailman.schlittermann.de