[gelöst] Pinning für LibreOffice?

[TuxPeter]

Hallo Debianfreunde,

eine kleine, nicht besonders wichtige, aber mich dennoch interessierende Frage:

Ich wollte Libre Office in Jessie vom "apt-get dist-upgrade" ausschließen, weil es immer so lange dauert, viel Traffic verursacht und ich das Office Paket sowieso nur selten brauche und mir eine neue Verson irgendwann später mal absolut reicht.

Deshalb habe ich, dank Debian-Wiki, folgendes File angelegt:
File: /etc/apt/preferences.d/libreoffice.pref

Code: Alles auswählen

Package: libreoffice
Pin: release n=jessie
Pin-Priority: 50

Dennoch gabs beim letzten Dist-Upgrade den ganzen Libreoffice-Kram komplett neu.

Wo ist mein Denkfehler?

Ich habe jetzt mal versuchsweise ein Sternchen drangehängt ("Package: libreoffice*") um alle Office-Teile einzeln auszuschließen, aber es gab aber noch keine Gelegenheit, das zu testen.

Oder ist ein solches Pinning gar nicht sinnvoll?

Grüße, TuxPeter

[rendegast]

Ich habe jetzt mal versuchsweise ein Sternchen drangehängt ("Package: libreoffice*") um alle Office-Teile einzeln auszuschließen,

Sollte funktionieren.

Code: Alles auswählen

apt-cache policy libreoffice libreoffice-writer ... ...

oder
aptitude versions libreoffice

Eventuell erweitern?

Code: Alles auswählen

Package: libreoffice* uno-libs3 ure
Pin: ...
Pin-Priority: ...

[TuxPeter]

Danke für die Antwort!
Habe es so übernommen und den Titel auf gelöst gesetzt.
(falls es wider Erwarten doch nicht funktioniert, kann ich ja den Thread auch wieder ausgraben)

Grüße, TuxPeter

[TuxPeter]

Tja, da muss ich wohl nochmal.

Beim letzten update && dist-upgrade bei Jessie hat es leider nicht funktioniert. Muntere 14 fette "libreoffice*"-Pakete hat er mir upgedatet. Nicht schlimm, aber Ziel verfehlt.

Warum? Die Datei sieht genauso aus wie oben beschrieben. Vielleicht funktioniert /etc/apt/preferences.d/xxx.pref nicht, wenn es kein File /etc/apt/preferences gibt? Sind die Unterverzeichnis-Inhalte *.d/*.pref etwa nur dann erlaubt, wenn es auch eine Hauptdatei dazu gibt? Habe das jetzt also eine Stufe zurückverlegt. Jetzt sieht es so aus. (Inhalt unverändert)

Code: Alles auswählen

root@d-1:/etc/apt# ls -la preferences
-rwxr-xr-x 1 root root 75 Jul 15 20:54 preferences
root@d-1:/etc/apt# cat preferences
Package: libreoffice* uno-libs3 ure
Pin: release n=jessie
Pin-Priority: 50

Es interessiert mich halt aus "rein sportlichen Gründen", sozusagen. Vielleicht sehr Ihr irgendwas, und ich hab Klöße auf den Augen.

Grüße, TuxPeter

[rendegast]

Fehlt wohl noch python-uno in der Liste?

Code: Alles auswählen

dpkg -l | grep 4.2.5

Vielleicht funktioniert /etc/apt/preferences.d/xxx.pref nicht,

Code: Alles auswählen

apt-cache policy libreoffice python-uno uni-libs3 ure

aptitude versions ^libreoffice$

[Apfelmann]

Ich mache es in solchen Fällen so:

su
echo das-zu-haltende-paket hold|dpkg --set-selections

damit wird das paket auf hold gesetzt und vom upgraden ausgenommen

LG

[TuxPeter]

Danke für Eure Hinweise,

mal sehen, was noch alles fehlt. ... Irgendwann lohnt sich das Gefummel nicht mehr, bloß um ein bisschen Bandbreite zu sparen.

Grüße, TuxPeter

[TuxPeter]

Hallo Debianfreunde,

habe zwar oben gelöst reingeschrieben - aber es funktioniert dennoch nicht.

mein /etc/apt/preferences sieht jetzt so aus:

Code: Alles auswählen

Package: libreoffice* python-uno uno-libs3 ure
Pin: release n=jessie
Pin-Priority: 50
/etc/apt/preferences (END)

(das Verz. ~preferences.d/ ist inzwischen leer)
Dennoch bringt der letzte dist-upgrade folgende Office-Pakete
(Ausschnitt von: apt-get -s dist-upgrade > textfile)

Code: Alles auswählen

Die folgenden Pakete werden aktualisiert (Upgrade):
  cpp-4.9 exim4 exim4-base exim4-config exim4-daemon-light fonts-opensymbol
  g++-4.9 gcc-4.9 gcc-4.9-base gcc-4.9-base:i386 libasan1 libatomic1
  libcilkrts5 libgcc-4.9-dev libgcc1 libgcc1:i386 libgfortran3 libgomp1
  libiec61883-0 libitm1 liblsan0 libmlt++3 libmlt-data libmlt6 libobjc4
  libofa0 libopenimageio1.4 libquadmath0 libreoffice
  libreoffice-avmedia-backend-gstreamer libreoffice-base libreoffice-base-core
  libreoffice-base-drivers libreoffice-calc libreoffice-common
  libreoffice-core libreoffice-draw libreoffice-help-de libreoffice-impress
  libreoffice-java-common libreoffice-l10n-de libreoffice-math
  libreoffice-report-builder-bin libreoffice-sdbc-firebird
  libreoffice-sdbc-hsqldb libreoffice-style-galaxy libreoffice-writer

Den Vorschalg von Apfelmann mit "hold" bedeutet, wenn ich es richtig verstehe, alle infrage kommenden Pakete einzeln aufzuführen. Und außerdem: irgendwann will ich ja doch dann auch mal LO updaten - nur halt nicht (fast) jedesmal. Ich weiß, es ist ein Luxusproblem, aber habt ihr vielleicht doch noch eine Idee?

Grüße, TuxPeter

[michaa7]

Also bevor ich mich da mit pinning herumquäle würde ich die wirklich auf hold setzen. Dazu mußt du nicht alle LO-pakete auf hold setzen, wenn du die wichtigsten pakete hälst, reicht das wohl, kannst dich ja rantasten.

apt-mark ist installiert?
Dann "apt-mark hold libreoffice libreoffice-base libreoffice-base-core <und vielleicht noch ein paar sich wichtig anhörende pakete>" ausführen. Ob das reicht kannst du ja einfach testen mit einem "apt-get update && apt-get dist-upgrade". Ab und an führst du mal ein "apt-get update && apt-get dist-upgrade --ignore-hold -d" aus um zu sehen was ohne dien holds passieren würde, das -d (für download but do not install) kannst du auch durch ein -s für simmulieren ersetzen. Der --ignore-hold schalter ist praktisch, weil du dann die pakete nicht extra "unhold"-en mußt um sie dannach wieder auf "hold" zu setzen.

Ich regle auf diese weise seit langem meine holds.

[TuxPeter]

Vielen Dank für die äußerst schnelle Antwort!

Das mit apt-mark werde ich auf jeden Fall ausprobieren.

[KBDCALLS]

Da fehlt noch * Also

Code: Alles auswählen

Package: libreoffice*
Pin: version 2.1.1*
Pin-Priority: 50

[rendegast]

mein /etc/apt/preferences sieht jetzt so aus:

Package: libreoffice* python-uno uno-libs3 ure
Pin: release n=jessie
Pin-Priority: 50
/etc/apt/preferences (END)

(Was soll die letzte Zeile?)

Es gibt ein weiteres uno-Paket, welches hier in einem jessie-Container gezogen würde:

Code: Alles auswählen

Package: libreoffice* python-uno uno-libs3 ure   python3-uno
Pin: release n=jessie
Pin-Priority: 50

Um es etwas allgemeiner zu halten:

Code: Alles auswählen

Package: libreoffice* python-uno uno-libs3 ure   python3-uno
Pin: version *
Pin-Priority: 50

Aber leider, es scheint wirklich so nicht zu funktionieren, hier Experimente in einem jessie-Container mit einem zurückgehaltenen rsyslog:

Code: Alles auswählen

Package: *
Pin: release a=now
Pin-Priority: 100


#Package: rsyslog
#Pin: version *
#Pin-Priority: 50

#Package: rsyslog
#Pin: version 7*
#Pin-Priority: 501

Package: rsyslog
Pin: version 8*
Pin-Priority: 49

#Package: rsyslog
#Pin: release a=*
#Pin-Priority: 48


#Package: *
#Pin: release a=*
#Pin-Priority: 99

(Eine Priority nur mit 'version *' träfe auch die installierte Version,
wodurch wieder die Version ausschlaggebend wäre,
somit einen expliziten Eintrag für die installierten Pakete 'release a=now' gemacht.)
Nach meinem Verständnis sollte obiges das Upgrade des rsyslog von 7.6.3 auf 8.2.2 verhindern.
Es gibt auch keine Pakete, die Version 8.2.2 explizit anfordern.
Dennoch ist 8.2.2 weiterhin der "Candidate":

Code: Alles auswählen

# apt-cache policy rsyslog
rsyslog:
  Installed: 7.6.3-3
  Candidate: 8.2.2-3
  Package pin: 8.2.2-3
  Version table:
     8.2.2-3 49
        500 http://ftp2.de.debian.org/debian/ jessie/main amd64 Packages
 *** 7.6.3-3 49
        100 /var/lib/dpkg/status

?????

Erst wenn ich per 'Pin-Priority: -1' das Paket explizit verbiete,
ist 8.2.2 nicht mehr "Candidate".
(?)(Genausogut wäre ein HOLD auf die installierte Version 7.6.3)
Weiterhin wirken unterdrückend Repo jessie auf 99 zu setzen, oder rsyslog version 7* auf 501.
Alles drei so nicht gewünscht.

Eventuell wird eine ein Paket treffende "Paket-Priority" anders gewertet
als eine für ein Repo gültige "Paket-Priority"
(im Beispiel die letzten auskommentierten Zeilen für 'release a=*') ?
So etwas lese ich aus der man-page allerdings nicht heraus(?),
sondern deute es aus den drei "funktionierenden" Priority-Werten.





-----------------------------
Anmerkung: die Dateien preferences und preferences.d/* unterliegen einem Formalismus.
Also zBsp. keinen Versatz einbauen:

Code: Alles auswählen

Package: libreoffice* python-uno uno-libs3 ure   python3-uno
  Pin: version *
  Pin-Priority: 50

Weiterhin wird eine Priority nicht akzeptiert mit einem direkt anschließenden Kommentar:

Code: Alles auswählen

Package: *
Pin: release a=*
Pin-Priority: 99
# laber comment bla

-> Kontrolle per 'apt-cache policy [paket(e)]'

[TuxPeter]

So,
Mit der Pin-Priority -1 funktioniert es jetzt, wie es soll.

Code: Alles auswählen

/etc/apt# cat preferences
Package: libreoffice* python-uno uno-libs3 ure python3-uno
Pin: version 1:4.2.5*
Pin-Priority: -1

Die bei mir jetzt installierte Version heißt 1:4.2.5-1+b1, installieren wollte er vorher was mit 1:4.2.6....

Vielen Dank für Eure Tipps und Hinweise!

TuxPeter

[rendegast]

Das unterbindet jetzt aber die schon installierte Version 4.2.5,
nicht ein eventuelles späteres Upgrade.
Also eher 'version 1:4.2*'.

Diese Lösung gefällt mir in dieser Art aber nicht.
Ich hätte es mir gewünscht wie bei den backports generell
Standard-Repo: 500
installierte: 100
backports: 100
-> (Nur) Manuelle Installation, Upgrades dafür möglich.
Was aber wie oben erwogen scheinbar nur für Repo-Prioritäten funktioniert, nicht für einzelne Pakete/Versionen.

Eine Alternative im Falle automatischer Upgrades durch das Paket unattended-upgrades,
dessen Blacklist, Bsp.:

Code: Alles auswählen

# apt-config dump | grep -i unatt
...
Unattended-Upgrade::Package-Blacklist:: "linux-headers-";
Unattended-Upgrade::Package-Blacklist:: "linux-image-";
Unattended-Upgrade::Package-Blacklist:: "linux-kbuild-";
Unattended-Upgrade::Package-Blacklist:: "linux-libc-dev";
Unattended-Upgrade::Package-Blacklist:: "virtualbox";
Unattended-Upgrade::Package-Blacklist:: "xen-linux-system";

->

Code: Alles auswählen

Unattended-Upgrade::Package-Blacklist:: "libreoffice";
Unattended-Upgrade::Package-Blacklist:: "python-uno";
Unattended-Upgrade::Package-Blacklist:: "python3-uno";
Unattended-Upgrade::Package-Blacklist:: "uno-libs3";

#Unattended-Upgrade::Package-Blacklist:: "ure";
#  Das nicht, da es durch die regex-Interpretation andere Pakete trifft

Über die Verwendung durch /etc/cron.daily/apt gäbe es einen Download dieser Pakete im vorherigen Schritt ->

Code: Alles auswählen

APT::Periodic::AutocleanInterval "1";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::Enable "1";
APT::Periodic::RandomSleep "11";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Update-Package-Lists "1";

[TuxPeter]

So, insgesamt bin ich jetzt - jedenfalls im Bezug auf dieses Thema - deutlich schlauer geworden. Elegant oder nicht - für mich reicht es erst mal.

Habe jetzt testweise noch einmal die 3 Zeilen in preferences auskommentiert und einen weiteren apt-get dist-upgrade laufen lassen. Der hat dann lediglich den ganzen Libre-Office-Kram von meiner vorherigen Version 1.4.2.5-1+b1 auf 1:4:2.6-1 gehoben. Das waren über 80 MB, etwa genauso viel wie der ganze Rest vorher (da war auch der Iceweasel bei), also es lohnt sich schon ... Die Änderung wirkt auch, wenn man danach kein apt-get update macht, was ich dank apt-cache (feines Prog, hatte ich bislang nicht verwendet) schon vor dem dist-upgrade sehen konnte.

Dann die neue Versionsnummer wieder in preferences eingetragen und entkommentiert, das kann dann so bleiben, bis vielleicht jessie mal auf Stable geht. Die Lib ure habe ich aus der Package-Liste wieder herausgenommen, ist aber egal, da sie sonst offensichtlich in meinem System nicht gebraucht wird.

Grüße, TuxPeter

[michaa7]

...
Habe jetzt testweise noch einmal die 3 Zeilen in preferences auskommentiert und einen weiteren apt-get dist-upgrade laufen lassen. ...

Da wäre ich aber mit der bewertung des tests sehr vorsichtig (um nicht zu sagen: du schießt dir selbst ins knie). preferences ist kein shellscript und die regeln für kommentare wie sie für scripte gelten sind hier nicht anwendbar.

Es mag sein, dass das auskommentieren aller einträge zum gewünschten ergebnis führt, quasi wegen unbrauchbarkeit, ein zeilenweises auskommentieren geht nicht, möglicherweise ist eine abgesetzte kommentarzeile am ende unschädlich, wie das rendegast angedeutet hat.

[TuxPeter]

Da wäre ich aber mit der bewertung des tests sehr vorsichtig

Klar, deshalb habe ich es ja vorher mit apt-cache policy libreoffice getestet. Vermutlich ist es einfacher, das File schlicht umzubenennen.