[gelöst] Paket-Manager - Updates auch für manuelle Installs?

[TomL]

Moin @ all

Gerade kommt mir eine Frage in den Sinn... und umso mehr ich darüber nachdenke, umso unsicherer werde ich. Der Paketmanager ist ja der Herr über alle durch "seine Tür" gegangenen Pakete... also alle Pakete, die z.B. ganz regulär mit apt-get installiert wurden, und natürlich auch die von vornherein zum System gehörenden Pakete. Und genau für die Pakete könnte ja beim apt-get upgrade oder apt-get dist-ugrade u.U. eine Aktualisierung durchgeführt werden. Wenn ich das richtig kapiert habe, führt das dann bei einigen Programmen möglicherweise auch zu einem Versionswechsel.... z.B. Firefox, oder VLC. Mein Eindruck aus der Vergangenheit war, dass die Maintainer gerade für diese beiden Programme öfter ein Aktualisierung der Paketquellen durchführen, hingegen für viele andere gar nicht oder nur, wenn gerade ein kritischer Patch ansteht.

Was mich jetzt aber verunsichert, ist die Frage nach der Situation, wenn ich z.B. das vorinstallierte Libre-Office deinstalliere und dann anschliessend "meine" Version (von der LO-Site) mit dpgk -i *.deb installiere. Und das im Zusammenhang mit der manchmal auftretenden Meldung, das bei einem "apt-get install xyz" der Hinweis erscheint, wurde als "manuell installiert" markiert. Dieser Hinweis kommt manchmal, wenn ein bestimmtes Paket schon vorhanden ist.

Bedeutet das, dass für alle Pakete, die ich via apt-get install oder dpkg -i selber und von Hand installiert habe, kein automatisches Update erfolgt - weil sie als "manuell installiert" markiert sind? Das wäre eigentlich so, wie ich das verstanden habe. Aber jetzt bin ich verunsichert, obs auch wirklich so ist. Denn wenn nicht, müsste ich die ja "anpinnen".... habe aber keine Ahnung, was das genau bedeutet und wie das geht. Aber wenn das nicht notwendig ist, will ich auch nix unnötiges machen.

Der Hintergrund für die Frage ist z.B. Thunderbird und Libre Office. Beide greifen von verschiedenen System auf die gleichen Daten zu. Thunderbird nutzt spezielle AddOns.... in beiden will ich kontiniuerliche Versions-Kompatibilität sicherstellen. Das heisst, habe ich sie von Hand installiert, will ich keine automatische Veränderungen. Kann das bei diesen von-Hand-Installationen passieren?

[Apfelmann]

Ich habe es immer so empfunden:
Updates gibt es auch für manuell installierte Pakete, um das zu verhindern müssen diese auf hold gesetzt werden.
Bei Installation durch Abhängigkeiten werden die Pakete als automatisch installiert gekennzeichnet und werden bei Deinstallation des Hauptpaketes für autoremove vorgeschlagen.

LG

[rendegast]

... und dann anschliessend "meine" Version (von der LO-Site) mit dpgk -i *.deb installiere.

Stammen aus einer von Dir heruntergeladenen Archiv-Datei.
Es gibt daher kein Repo, das eines der dpkg-Frontends "beobachten" kann.

Es bestünde die Möglichkeit, ein Repo selbst zu erzeugen
(Ich bevorzuge 'apt-ftparchive' aus apt-utils).
Zum "guten Ton" würde dann noch eine (selbsterzeugte) Signierung des Repo gehören.

Der Vorgang kann automatisiert werden:
Download bei neuer LO-Version > Entpacken > Erzeugung des Repo (+Signierung)

[TomL]

Moin

... und dann anschliessend "meine" Version (von der LO-Site) mit dpgk -i *.deb installiere.

Stammen aus einer von Dir heruntergeladenen Archiv-Datei. Es gibt daher kein Repo, das eines der dpkg-Frontends "beobachten" kann.

Wenn ich das jetzt richtig verstehe bedeutet das, dass meine manuell installierte Libre-Office-Version nie aus dem offiziellen Repo aktualisiert wird....? Und es bedeutet, dass meine derzeit aktuellere Version langsam und irgendwann von den Versionen im Repo überholt werden würde, wenn ich jetzt dauerhaft nichts verändern würde...?

Mir ist das klar, wenn es z.B. um xnviewmp gehen würde. Das gibts nicht im Repo, ich habs aus ne anderen Quelle installiert..... also kann da auch nichts beobachtet oder aktualisiert werden. Aber mir ist der Zusammenhang mit Firefox, Thunderbird und LO nicht so recht klar.... denn die gibts ja sowohl im Repo als auch als Install aus dem Web. Und ich habe jetzt Thundebird und LO aus einem Paket direkt von der "Hersteller"-Website installiert, und zwar die Versionen, die mir die AddOn-Kompatibilität gewährleisten. Das Problem bei Thunderbird ist ja, dass die AddOns nicht im Front-End gespeichert werden, sondern quasi im Back-End, also im irgendwo auf dem Server gespeicherten Profil. Und das wird eben von verschiedenen Maschinen aus bearbeitet. Ich bin halt insofern unsicher, weil es sich hier aus Sicht des Repo's um "bekannte und unterstützte" Pakete handelt, die beide (aus Repo o. Netz) eigentlich durch den Paketmanager installiert worden sind bzw. werden würden.

[rendegast]

Wenn ich das jetzt richtig verstehe bedeutet das, dass meine manuell installierte Libre-Office-Version nie aus dem offiziellen Repo aktualisiert wird....?

Wenn eine Version aus dem Repo (sources.list[.d/], preferences) diese Pakete "überholt",
so werden sie ausgetauscht.
Tools zBsp.

Code: Alles auswählen

apt-cache policy [|grep -v Translat]
apt-cache policy paket1 paket2 paket3 ...

aptitude versions ^paket1$ ^paket2$ ^paket3$ ...

und natürlich die dpkg-Frontends in Simulationsschaltung

Code: Alles auswählen

apt-get --simulate [dist-]upgrade [--no-install-recommends]
aptitude --simulate [dist-]upgrade [--without-recommends]

Deine addons werden unter firefox/thunderbird aus addons.mozilla.org aktuell gehalten.
Unter den debian-Pendants iceweasel/icedove bin ich mit nicht sicher,
zumindest das Upgrade(Probe) der Programme selbst ist aus diesen herausgepatcht,
wird ja vom debian-Paketmanagement erledigt,
und der Benutzer des Programms hat normalerweise auch kein Schreibrecht an den Programmverzeichnissen (da er/sie/es nicht root ist).
Die addons beinhalten normalerweise Information über ihre Upgrade-Quelle,
bei den von debian bereitgestellten dürfte diese entfernt sein.
Über den Sinn, addons von debian bereitzustellen, kann wahrlich gestritten werden.

Hat der Benutzer des firefox/thunderbird Schreibrecht in deren Verzeichnissen,
so wird das Programm-Upgrade vom Programm bei Ausführung erledigt.

[TomL]

Moin rendegast

Das war sehr interessant und wieder war neues gelernt.... aber auch wieder eine neue Unklarheit. Ich habe mir das mal bei meinem Firefox angesehen... das ist nämlich im Moment noch der reguläre Installationskandidat. So sieht das aus:

Code: Alles auswählen

thomaspc thomas # dpkg -l firefox
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name                            Version              Architektur          Beschreibung
+++-===============================-====================-====================-=======================
ii  firefox                         40.0~linuxmint3+bets amd64                The Firefox web browser

Und dazu passend und übereinstimmend:

Code: Alles auswählen

thomaspc thomas # apt-cache policy firefox
firefox:
  Installiert:           40.0~linuxmint3+betsy
  Installationskandidat: 40.0~linuxmint3+betsy
  Versionstabelle:
 *** 40.0~linuxmint3+betsy 0
        700 http://packages.linuxmint.com/ betsy/import amd64 Packages
        100 /var/lib/dpkg/status
thomaspc thomas #

Schaue ich mir das gleiche mit LibreOffice an, fällt ein markanter Unterschied auf:

Code: Alles auswählen

thomaspc thomas # dpkg -l libreoffice*
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name                            Version              Architektur          Beschreibung
+++-===============================-====================-====================-===============================================
ii  libreoffice4.3                  4.3.7.2-2            amd64                Brand module for LibreOffice 4.3 .7.2
ii  libreoffice4.3-base             4.3.7.2-2            amd64                Base brand module for LibreOffice 4.3 .7.2
ii  libreoffice4.3-calc             4.3.7.2-2            amd64                Calc brand module for LibreOffice 4.3 .7.2
ii  libreoffice4.3-de               4.3.7.2-2            amd64                Brand language module for LibreOffice 4.3 .7.2
ii  libreoffice4.3-debian-menus     4.3.7-2              all                  LibreOffice 4.3 desktop integration
ii  libreoffice4.3-dict-de          4.3.7.2-2            amd64                De dictionary for LibreOffice 4.3 .7.2
ii  libreoffice4.3-dict-en          4.3.7.2-2            amd64                En dictionary for LibreOffice 4.3 .7.2
ii  libreoffice4.3-dict-es          4.3.7.2-2            amd64                Es dictionary for LibreOffice 4.3 .7.2
ii  libreoffice4.3-dict-fr          4.3.7.2-2            amd64                Fr dictionary for LibreOffice 4.3 .7.2
ii  libreoffice4.3-draw             4.3.7.2-2            amd64                Draw brand module for LibreOffice 4.3 .7.2
ii  libreoffice4.3-en-us            4.3.7.2-2            amd64                Brand language module for LibreOffice 4.3 .7.2
ii  libreoffice4.3-impress          4.3.7.2-2            amd64                Impress brand module for LibreOffice 4.3 .7.2
ii  libreoffice4.3-math             4.3.7.2-2            amd64                Math brand module for LibreOffice 4.3 .7.2
ii  libreoffice4.3-ure              4.3.7.2-2            amd64                UNO Runtime Environment .7.2
ii  libreoffice4.3-writer           4.3.7.2-2            amd64                Writer brand module for LibreOffice 4.3 .7.2
thomaspc thomas #

Code: Alles auswählen

thomaspc thomas # apt-cache policy libreoffice
libreoffice:
  Installiert:           (keine)
  Installationskandidat: 1:4.3.3-2+deb8u1
  Versionstabelle:
     1:4.3.3-2+deb8u1 0
        500 http://ftp.us.debian.org/debian/ jessie/main amd64 Packages
        500 http://security.debian.org/ jessie/updates/main amd64 Packages
thomaspc thomas # 

Der markante Unterschied ist hier: Installiert: (keine). Und genau wegen diesem Umstand, bin ich die ganze Zeit unsicher wegen für mich widersprüchlicher Texte und Aussagen, bei dem, was ich so im Netz gefunden habe.

Wenn eine Version aus dem Repo (sources.list[.d/], preferences) diese Pakete "überholt", so werden sie ausgetauscht.

Ist das wirklich so? Die Abfrage "apt-cache policy libreoffice" antwortet ja, das es gar nicht installiert ist... wieso sollte er da updaten? Oder es ändert sich automatisch, wenn der Installationskandidat hinsichtlich der Versionsnummer genau gleich oder "jünger" wäre. Aber das würde ich nicht verstehen, denn es wird ja hier festgestellt "gar nicht installiert".

[rendegast]

libreoffice (debian) ist NICHT libreoffice4.3 (libreoffice.org).
Somit wird libreoffice* (debian) dann doch nicht Deine Pakete libreoffice4.3* ersetzen.



------------------------------------
linuxmint sollte als 3rd-Party Repo nicht Priority 700 besitzen.

[TomL]

libreoffice (debian) ist NICHT libreoffice4.3 (libreoffice.org).

.... oh mann.... da muss man erst mal drauf kommen.... na klar, wenn das Debian-LibreOffice immer (unabhängig von der Version) libreoffice heist, dann wird meins nie upgedatet werden., weils eben gar nix upzudaten gibt.

Danke für diese ausgesprochen informative Lernstunde

linuxmint sollte als 3rd-Party Repo nicht Priority 700 besitzen.

Auch dann nicht, wenn ich da gar nicht dran geschraubt habe? Das ist noch alles so, wie es der Installer eingerichtet hat.

[uname]

Macht es Sinn von Zeit zu Zeit mal zu schauen ob es Pakete gibt, wo die Zuordnung nicht stimmt oder steht das alles sowieso in /var/lib/dpkg/status:

Code: Alles auswählen

for i in $(dpkg -l|grep "^ii" |cut -d" " -f3 );do apt-cache policy $i |grep -A1 -B1 "Installiert:"|tr '\n' ';';echo; done

Ausgabe umleiten und dann z.B. weitersuchen.

[rendegast]

<linuxmint>
Auch dann nicht, wenn ich da gar nicht dran geschraubt habe? Das ist noch alles so, wie es der Installer eingerichtet hat.

Seltsam, aber so kann mensch sich ins Knie schiessen.

Also eher sowas

Code: Alles auswählen

Package: *
Pin: origin packages.linuxmint.com
Pin-Priority: 100

Ich habe hier

Code: Alles auswählen

< eine gewachsene Auflistung von Repo mit Prio <=500 >

# "catchall"
Package: *
Pin: release a=now
Pin-Priority: 100

Package: *
Pin: release a=*
Pin-Priority: 88

Package: *
Pin: origin "*"
Pin-Priority: 9

Die obige Liste entsteht dabei aus Dateien
/etc/apt/preferences.d/00_blafoo.pref,
Das Ende als
/etc/apt/preferences.d/zz.pref.
/etc/apt/preferences bleibt dabei leer.

Ein von irgendeinem Installer/Paketskript gesetzte Priority wird sich höchstwahrscheinlich nicht an mein Schema halten und fällt schnell auf.
-> Fliegt dann auch schnell wieder heraus.
Alle Repo, die ich testweise mal hinzufüge, und deren Pakete nicht versuchen an der Preference/Priority herumzuschrauben,
fallen in der Liste 'apt-cache policy' auf, können zudem nicht einfach so Pakete hineinschieben.

[rendegast]

Macht es Sinn von Zeit zu Zeit mal zu schauen ...

Sicher, ich würde aber anderes bevorzugen.
Dein Skript ~>

Code: Alles auswählen

apt -cache policy $(aptitude search "?installed") | .....

Tool apt-show-versions

Die nicht-installierten Pakete im Blick behalten

Code: Alles auswählen

dpkg -l | egrep -v "^ii"

(das läßt sich ganz gut durch Setzen von Purge statt Remove in den Griff kriegen

Code: Alles auswählen

APT::Get::AutomaticRemove "true";
APT::Get::Purge "true";
Aptitude::Purge-Unused "true";

Konfig kann ja aus dem Backup geholt werden, zBsp. etckeeper.
Die meisten Pakete belassen hidden-Dateien/Verzeichnisse (für eigene Anmerkungen usw.) ohnehin in den Konfig-Verzeichnissen,
einige (dansguardian) machen aber auch ein "brutales" 'rm -rf $Konfig-dir'.)

[TomL]

<linuxmint>
Auch dann nicht, wenn ich da gar nicht dran geschraubt habe? Das ist noch alles so, wie es der Installer eingerichtet hat.

Seltsam, aber so kann mensch sich ins Knie schiessen.

Also eher sowas

Code: Alles auswählen

Package: *
Pin: origin packages.linuxmint.com
Pin-Priority: 100

An dem Punkt angekommen setzt es bei mir aus.... damit bin ich total überfordert. Ich habe mir das mit der Pin-Priority gerade mal bei Ubuntuusers durchgelesen und in dem Zusammenhang meine /etc/apt/preferences.d/official-package-repositories.pref geprüft, die folgendes enthält:

Code: Alles auswählen

Package: *
Pin: origin packages.linuxmint.com
Pin-Priority: 700

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

Das jetzt hier Linux Mint die höhere Priorität hat und sich deshalb bei der Paket-Wahl durchsetzen würde, scheint mir nicht nur völlig logisch, sondern sogar zwingend. Eigentlich hätte ich das jetzt so eingeschätzt, dass eher Debian die 3rd-Party-Repo ist..... und primär kommt alles aus Minit, nur der Rest aus Debian. Nach meiner Meinung habe ich ja auch gar kein Debian installiert, sondern ein Linux Mint LMDE, welches auf Debian basiert. Das ist aber doch was anderes, als würde ich den Jessie-Installer downloaden und von dort Cinnamon installieren. Dann wäre das klar, dann dürfte die Mint-Priority niemals höher als die von Debian sein.

[rendegast]

Ach so.
Ich bin von einem Stamm-debian ausgegangen (debianforum und so),
und zur Einspielung (nur) des firefox eine Einbindung des linuxmint-Repo.

[TomL]

Ach so.Ich bin von einem Stamm-debian ausgegangen (debianforum und so),

Ich fühle mich aber trotzdem noch als "Debianer"

und zur Einspielung (nur) des firefox eine Einbindung des linuxmint-Repo.

*pfffffffft* ich hatte schon nen Schrecken gekriegt....

Nee, Firefox, Thunderbird und Libreoffice hole ich mir immer direkt vom "Hersteller" und installiere es eben von Hand..... und habe bisher noch keine schlechten Erfahrungen damit gemacht. An der sources.list schraube ich nicht einfach so rum. Zuerst immer im eigenen Haus suchen, alternativ (wenns dort nicht verfügbar ist) ggf. ein deb-Package für Debian 8 von der Programm-Seite. Und wenn das auch nicht geht, dann versuch ich es selber zu kompilieren. Mir mit falschen Einstellungen in den sources.list den Rechner zu zerschroten habe ich nullbock drauf *lol*