apt: Pinnen oder nicht pinnen?

[zoe]

Ich habe wegen einem Paket debian-multimedia.org eingepfelgt. Nach der Installation habe ich die Quelle wieder deaktiviert, weil mir Aktuallisierungen von Paketen vorgeschlagen wurden, die mir von den Standard-Quellen nicht vorgeschlagen wurden. Muss bzw. sollte ich nun das Paket und evtl. dessen Abhängigkeiten aus debian-multimedia.org pinnen oder nicht, wenn ich auf Nummer Sicher gehen möchte?

[Luxuslurch]

Du musst natürlich nicht, aber wenn du eine Quelle deaktivierst, kriegst du auch keine Updates mehr von dort. apt-pinning ist vor allem für die Priorisierung der Quellen (und Pakete) da. Damit kriegst du es auch hin, dass du nur die Aktualisierung für die installierten Pakete bekommst, nicht aber automatisch die höheren Paketversionen aus einer Quelle (z.B. multimedia) Pakete aus einer anderen Quelle (z.B. squeeze) überbügeln. Ein Eintrag in die /etc/apt/preferences könnte so aussehen:

Code: Alles auswählen

Package: *
Pin: origin www.debian-multimedia.org
Pin-Priority: 200

Näheres dazu unter im Anwenderhandbuch

[zoe]

Meine Überlegung war, dass ich nach der Deaktivierung evtl. ein Paket aus den Standard-Quellen bekommen könnte, das dann eines aus Multimedia irgendwie - wie auch immer - kaputt macht, sofern zum Beispiel der Name gleich ist. Mir geht es auch vielmehr darum, das grundsätzlich zu klären, wie man das macht, wenn man eben unbedingt etwas braucht, das nicht Debian-Standard ist.

[Luxuslurch]

In der Regel liegen die Pakete von debian-multimedia in einer höheren Version vor. Deaktivierst du diese Quelle, wird natürlich früher (bei sid z.B.) oder später (bei stable) eine neuere Version gleichen Namens in den Quellen vorliegen und diese überschreiben. Insofern ist deine Befürchtung vollkommen berechtigt.
Was man dagegen unternimmt, ist wiederum eine andere Sache und kann von Fall zu Fall variieren. Ich persönlich würde nicht die Fremdquelle deaktivieren, sondern so wie oben beschrieben zähmen.

[gxyz]

Meine Überlegung war, dass ich nach der Deaktivierung evtl. ein Paket aus den Standard-Quellen bekommen könnte, das dann eines aus Multimedia irgendwie - wie auch immer - kaputt macht, sofern zum Beispiel der Name gleich ist. Mir geht es auch vielmehr darum, das grundsätzlich zu klären, wie man das macht, wenn man eben unbedingt etwas braucht, das nicht Debian-Standard ist.

Wie ich aus leidvoller Erfahrung sagen kann, keine unrealistische Befürchtung - wobei Inkompatibilitäten durchaus in beide Richtungen auftreten können, so dass es keine Strategie gibt, die in jedem Falle vor Komplikationen bewahrt (wenn Du tatsächlich nur ein einziges Paket aus Multimedia hast und keine anderen Pakete davon abhängen kannst Du das Ganze natürlich ohne Gefahr von Seiteneffekten einfrieren, indem Du einfach den Namen des Pakets änderst; selbst dann kann's natürlich noch Probleme mit gleichen Dateinamen geben ...).

Leider gibt es keine gute Lösung, denn aus diversen Gründen sind viele Debian-Pakete in dem Sektor aus kaum behebbaren Gründen (Patente etc.) nur sehr rudimentär brauchbar. Ich persönlich bin dazu übergegangen, bei haarigen Sachen, die ich öfters brauche alle benötigten Komponenten aus den Quellen zu kompilieren und unter einem gemeinsamen Präfix (z.B. "/opt/xy471") zu installieren, der außer allgemeinen Sachen wie libc, X11 etc. möglichst keine externen Abhängigkeiten enthält (was natürlich ein ziemlicher Aufwand ist und u.U.. RAM vergeudet ...)

[Luxuslurch]

Ja, multimedia ist eine heikle Fremdquelle (siehe den sticky-thread)
Was auch möglich ist: eine minimal-Installation zunächst mit freigeschalteten multimedia-quellen zu füttern, also alle benötigten Pakete unter Einbezug der Quelle zu installieren. Anschließend wird sie auf 200 gepinnt, um keine unerwünschten Pakete zu installieren. Jetzt sind alle relevanten Pakete aus der einen Quelle - und verursachen bei mir zumindest keine Inkompatibilitäten oder Abhängigkeitsprobleme mehr.

[zoe]

Und wenn ich mir alle Pakete inklusive Abhängigkeiten manuell als .deb herunterlade und pinne, die Quelle erst gar nicht einpflege? Das sollte doch relativ sicher sein, andere Sicherheitsrisiken mal außer Acht gelassen. Nicht?

[Luxuslurch]

Na, wenn du die Quelle nicht in die sources.list aufnimmst, brauchst du sie natürlich auch nicht pinnen. Nur kriegst du dann keine updates mehr. Bei wenigen Paketen ist das aber eine recht verbreitete Vorgehensweise, glaube ich zumindest.

[zoe]

Nein, ich meinte, dass ich die Versionen der manuell installierten Pakete pinne, um auszuschließen, dass mir via Update vielleicht doch durch irgendeine kleine Unachtsamkeit eine originale Debian-Version auf den Rechner kommt. So müsste es doch schon gut sein. Updates könnte man dann von Zeit zu Zeit von Hand machen. Müsste klappen. Oder?

[Cae]

Nein, ich meinte, dass ich die Versionen der manuell installierten Pakete pinne, um auszuschließen, dass mir via Update vielleicht doch durch irgendeine kleine Unachtsamkeit eine originale Debian-Version auf den Rechner kommt. So müsste es doch schon gut sein. Updates könnte man dann von Zeit zu Zeit von Hand machen. Müsste klappen. Oder?

Das sagte doch dein Vorposter?! Zumindest meinte er das und ich denke dies auch:

Na, wenn du die Quelle nicht in die sources.list aufnimmst, brauchst du sie natürlich auch nicht pinnen. Nur kriegst du dann keine updates mehr. Bei wenigen Paketen ist das aber eine recht verbreitete Vorgehensweise, glaube ich zumindest.

Gruß Cae

[Luxuslurch]

Das war i.d.T. der Kern meiner Aussage.

Bereits Installierte Pakete kriegen nämlich eine Priorität von 100. Eine Paket in einer Quelle (auch d-m) hat in der Regel eine Priorität von 500, weswegen neuere Versionen dieses Paketes gegenüber der lokal installierten Version bevorzugt werden.

=> Existiert allerdings dieses Paket in keiner Quelle, so kann apt natürlich auch nix bevorzugen. Woher auch

[zoe]

Das war jetzt vielleicht ein Missverständnis.

Das Paket vlc zum Beispiel existiert bei DM und ich kann es auch aus den Debian-Repos installieren. Vielleicht denke ich mir das jetzt ein bisschen zu umständlich.
Ich werde das also jetzt einfach so machen, dass ich das alles händisch einpflege und die Versionen pinne.

[Luxuslurch]

Stimmt, bei Paketen, die in beiden Quellen gleichermaßen existieren, kann es zu Unverträglichkeiten kommen. Wenn ich dich richtig verstanden habe, sieht deine Vorgehensweise jetzt so aus, dass du einzelne Pakete (z.B. VLC) explizit auf eine Version pinnen möchtest? Das ist auch möglich. Bedenke bitte aber, dass jedes Paket auch Abhängigkeiten hat.

[zoe]

Klar.

Gut, dann hätten wir das geklärt. Danke.

[zoe]

So, nun doch nochmal zum Thema:

Und zwar habe ich mir testweise ein Debian gedebootstrapt und nutze das nun via schroot in einer chroot-Umgebung, als Nutzer habe ich mir einfach meinen Nutzer gegeben, debian-multimedia.org in der chroot-Umgebung eingepflegt, etc. Das müsste doch eigentlich noch sicherer sein als das Pinnen oder Kompilieren oder Pakete händisch pflegen. Und vor allem, abgesehen von der Einrichtung, am unaufwendigsten, wenn was nicht läuft, wie es soll (rm -R ) . Oder?

[chb]

Hallo zoe,
je nach dem, ob Du von einem Sytem redest, auf dem Serverdienste laufen, oder von einem überwiegend privat genutzten Desktoprechner wird man sicher unterschiedliche Stabilitätsprioritäten ansetzen wollen /müssen.

Auf dem überwiegend privat genutzten System halte ich idR. Stabilitätsparanioa hinsichtlich Fremdquellen -Einflüssen für vollkommen überbewertet. GNU/Debian ist ein sehr robustes Sytem mit einer nahezu perfekten Versions- & Quellenverwaltung - so schnell geht da kein System 'hops'. Regelmäßige, brauchbare Backups sind ohnehin Pflicht!
Auf einem Sytem fahre ich seit Jahren 'testing' mit Zusatzquellen stable-backports, sid & experimental, bunt gemischt mit reichlich Fremdquellen und Selbstcompiliertem, der 'Frickelrechner' musste dazu noch 'crossgrades' von testing (squeeze) > crunchbang > testing (wheezy) > siduction überstehen... das einzige mal, bei dem tatsächlich ein Backup eingespielt werden musste, war definit in eigener Blödheit begründet, nicht in 'Fremdquellen'.

[zoe]

Ich habe keine Paranoia, sondern möchte es eben möglichst ordentlich machen. Ich saß erst kürzlich mit einem nicht funktionierendem Mplayer da, nicht, dass das jetzt so schlimm gewesen wäre. Aber manchmal ist sowas halt nervig, auch wenn es nur der Rechner zu Hause war.

[guennid]

Mein bescheidener Vorschlag wäre, externe Repos nur temporär und gezielt für ein bestimmtes Projekt in der sources.list einzubinden. Damit bin ich bisher ganz gut gefahren. Soviel wird es ja nicht sein, was man als Privatmensch "für den Hausgebrauch" z.B. aus Multimedia benutzen müsste. Das lässt sich beherrschen, wenn man sich angewöhnt, vor jeder Programminstallation mit apt-get/aptitude -s install ... zu arbeiten und im Zweifelsfall nachzufragen.

@chb: die "eigene Blödheit" ist natürlich ein recht dehnbarer Begriff.

Grüße, Günther

[chb]

Ich habe keine Paranoia

Beware -- ich wollte keinesfalls Dir persönlich Paranoia unterstellen oder Dich angreifen! Ich sprach ausschließlich von der Policy bzw. Sichtweise, die stark gefüttert wird durch die unangenehmen Erlebnisse noch unerfahrener User, die 19 Fremdquellen in sources.list kopieren (weil's irgendwo im Netz so stand), nach 7 Monaten dann 'mal so' upgraden und von den evtl. umfangreichen Kleinreparaturen dann überfordert sind. Und natürlich vorher kein Backup gemacht haben.

Hinsichtlich Deiner ursprünglichen Frage - imho ist Pinning eine prima Sache, entbindet aber nicht davon, Systemmeldungen aufmerksam zu lesen und präferenzabhängige Entscheidungen zu treffen. Da Du nicht schriebst, um welche d-m Pakete es geht, fällt eine sachgerechte Antwort schwer. Wenn's nur ein non-free codec war, kannst Du d-m getrost rauskommentieren und alle paar Monate /nach Bedarf gezielt nach einem Update suchen (if it works, don' fix it).

@guennid: allerdings - Tippfehler bei dd in der root Konsole(!) ...falsches of ...und ex

[Dogge]

Hallo,

ich wollte mein apt so konfigurieren, dass normalerweise immer aus testing installiert wird. Sollte das Paket dort mal nicht vorhanden sein (WINE fehlte z.B. mal), dann soll erst in unstable dann aus experimental installiert werden (für den Fall, dass es etwas brandneues ist).
Das funktioniert mit den ersten drei Einträgen auch ganz gut.

Jetzt kommt multimedia ins Spiel. Pakete, die in debian nicht vorhanden sind (z.B. dvd95 und libdvdcss2) sollen aus d-m geholt werden und auch von dort updates beziehen. Sind sie jedoch in testing/unstable/experimental vorhanden soll diese Version installiert werden.

Mit folgender Konfiguration will apt jedoch auch vlc etc. auf die d-m Version updaten.

Code: Alles auswählen

Package: *
Pin: release a=testing
Pin-Priority: 900

Package: *
Pin: release a=unstable
Pin-Priority: 400

Package: *
Pin: release a=experimental
Pin-Priority: 250

Package: *
Pin: origin www.debian-multimedia.org
Pin-Priority: 200

Wenn installierte Pakete eine Priorität von 100 haben könnte ich ja mit einer d-m Priorität von <= 100 erreichen, dass von dort installiert wird wenn das Paket nicht installiert und in keiner anderen Quelle vorhanden ist.
Aber ich verstehe es so, dass ich dann auch keine updates mehr bekommen würde, da das installierte Paket dann ja wiederum eine Priorität von 100 hätte, was ja auch der Grund ist dass apt die aktuell installierten testing Pakete mit d-m Paketen ersetzen will.

Kann es zu Konflikten zwischen Pin origin und release kommen? Pakete aus der Quelle d-m haben ja auch das release testing. Welcher Pin ist in so einem Fall dominant?

Wenn ich hier einen grundlegenden Denkfehler drin habe, oder eine Möglichkeit genau das, von mir gewünschte, Verhalten zu erreichen wäre ich für Hilfe dankbar.

Ich hoffe es ist ok, dass ich keinen eigenen Thread eröffnet habe, dieser hier passt thematisch ja exakt auf mein Problem.

[Dogge]

Ok, hab jetzt diverse Einträge in /etc/apt/preferences getest und danach mittels "apt-cache policy mplayer" den Status überprüft.

Ich bekomme es einfach nicht hin, normales testing dem d-m vorzuziehen. Irgendwie gelten für beide repos immer die gleichen Prioritäten.
Ich habe alle Kombinationen durchgeprüft, die mir möglich schienen um release und origin zu verknüpfen, aber scheinbar scheint das immer verODERt, statt verUNDet zu werden.
Entweder ich bin zu blöd dazu, oder diese Möglichkeit besteht gar nicht. In den manpages und via Internet finde ich jedenfalls nichts, obwohl ich mir nicht vorstellen kann, dass ich der erste bin der sein apt so konfigurieren will, dass nicht alles aus einem bestimmten repo installiert wird ohne extra für jedes einzelne Paket einen Eintrag erstellen zu müssen...

[Dogge]

Ok, ich habe eine Lösung gefunden. Wenn ich d-m einfach komplett aus der preferences Datei rauslasse, dann hat testing Prio 900 und das neue Paket aus d-m automatisch 500 und damit funktioniert es anscheinend so wie ich möchte. Zumindest will "apt-get dist-upgrade" jetzt nichts mehr updaten.

Da habe ich es mir selbst zu kompliziert gemacht indem ich d-m mit in die /etc/apt/preferences hineingenommen habe.

Hier der aktuelle Status:

Code: Alles auswählen

Package: *
Pin: release o=debian,a=testing
Pin-Priority: 900

Package: *
Pin: release o=debian,a=unstable
Pin-Priority: 400

Package: *
Pin: release o=debian,a=experimental
Pin-Priority: 250

Code: Alles auswählen

root@schlepptop:~# apt-cache policy mplayer
mplayer:
  Installiert: 2:1.0~rc4.dfsg1+svn34540-1+b2
  Kandidat:    2:1.0~rc4.dfsg1+svn34540-1+b2
  Versionstabelle:
     3:1.0~rc4+svn20120514-dmo1 0
        500 http://debian-multimedia.org/ testing/main amd64 Packages
        500 http://debian-multimedia.org/ unstable/main amd64 Packages
 *** 2:1.0~rc4.dfsg1+svn34540-1+b2 0
        900 http://ftp.de.debian.org/debian/ testing/main amd64 Packages
        400 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
        100 /var/lib/dpkg/status

root@schlepptop:~# apt-get dist-upgrade 
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut       
Statusinformationen werden eingelesen... Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

Edit: Ach ja, eine nötige Änderung war "release a=testing" in "release o=debian,a=testing" zu ändern, da ansonsten die testing Pakete aus d-m ebenfalls Prio 900 zugewiesen bekommen.
Nur für den Fall, dass jemand mal an der gleichen Stelle hängt wie ich vorhin.

[sidloki]

So sollte es funktionieren:

Code: Alles auswählen

Package: *
Pin: release o=Debian,a=testing
Pin-Priority: 500

Package: *
Pin: release o=Debian,a=unstable
Pin-Priority: 400

Package: *
Pin: release o=Debian,a=experimental
Pin-Priority: 300

Package: *
Pin: release o=Unofficial Multimedia Packages,a=testing
Pin-Priority: 200