(Un)Install-Reihenfolge bei Dependencies

Antworten
Benutzeravatar
jub
Beiträge: 58
Registriert: 25 Nov 2010, 12:40

(Un)Install-Reihenfolge bei Dependencies

Beitrag von jub »

Hallo allerseits,

ich stolpere gerade ueber die Dependencies einiger meiner Pakete (wahrscheinlich ist es wirklich zu heiss).

Ein Beispiel:

Paket: firefox-esr-legacy (Postition 157):

Code: Alles auswählen

[ProductDependency]
action: setup
requiredProduct: firefox-esr
requiredStatus: not_installed
requirementType: before
Paket: firefox-esr (Position 234):

Code: Alles auswählen

[ProductDependency]
action: setup
requiredProduct: firefox-esr-legacy
requiredStatus: not_installed
requirementType: before
Ist nun beispielsweise firefox-esr auf einem Client installiert und es wird firefox-esr-legacy zur Installation markiert, so wird das bereits installierte Paket korrekt automatisch zur Deinstallation marktiert.
Allerdings fuehrt der Client nun doch zunaechst die Installation von firefox-esr-legacy (gemaess Position) aus und entfernt erst anschliessend das firefox-esr. (Da beide Pakete die Software im gleichen Verzeichnis installieren, ist im Anschluss keines der Pakete mehr installiert, obwohl firefox-esr-legacy das von sich logischerweise behauptet.)

Workaround 1
Ich lasse die ProductDependency weg.
Da die jeweiligen Pakete beim Setup ohnehin jede bestehende Installation zuvor sauber tilgen (egal ob ESR, nicht-ESR, ESR-legacy, Test-Paket), ist zumindest keine alte Version im Wege. Per opsiServiceCall-Methode productOnClient_updateObjects wird dann targetConfiguration und installationStatus fuer das "zu entfernende" Paket bereinigt.

Nachteil:
  • Die Pakete werden etwas komplexer, auch wenn die jeweiligen Funktionen in Local Functions ausgelagert werden koennen.
  • Das ganze funktioniert nur, wenn der Uninstaller von Paket A auch Paket B sauber deinstallieren kann. Damit ist dieser Ansatz leider nicht universell.
Workaround 2 (schoen, funktioniert nur nicht)
Auch hier gibt es keine ProductDependency.
Es wird ein Meta-Paket erstellt, in dem die gewuenschte Version per Property gewaehlt wird. Per opsiServiceCall-Methode setProductActionRequest werden die jeweiligen Pakete fuer install bzw. uninstall markiert.

Problem:
  • Die Methode hostControlSafe_fireEvent laesst sich hier nicht verwenden. ("Backend permission denied error: Access to method 'hostControlSafe_fireEvent' denied for user ...") Das erscheint hier ohnehin nicht sinnvoll.
  • Ich kann aus einem Setup-Skript eines Paketes m.W. kein anderes Paket gemaess seiner Objekteinstellungen ausfuehren.
  • Der Client muss also ein weiteres Mal die Paketliste durchlaufen (Reboot oder OnDemand) um die (De)Installation letztendlich auszufuehren. Dabei schlaegt aber wieder das Problem der Position der Pakete zu. Insofern ist das keine Loesung fuer das eigentliche Problem.
Viele Gruesse,
Jens
Benutzeravatar
jub
Beiträge: 58
Registriert: 25 Nov 2010, 12:40

Re: (Un)Install-Reihenfolge bei Dependencies

Beitrag von jub »

Ich sehe gerade, es gibt zu dem Thema einen weiteren Thread: Installationsreihenfolge mit Dependencies und Algorithm1.
Benutzeravatar
r.roeder
uib-Team
Beiträge: 540
Registriert: 02 Jul 2008, 10:08

Re: (Un)Install-Reihenfolge bei Dependencies

Beitrag von r.roeder »

Bitte schau auch mal in viewtopic.php?t=8274#p36067

Kurz gesagt: Die Dependencies sind derzeit für uninstall nicht konzipiert
opsi support - uib gmbh
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.


Wondering who's using opsi? Have a look at the opsi map: http://opsi.org/opsi-map/.
Benutzeravatar
jub
Beiträge: 58
Registriert: 25 Nov 2010, 12:40

Re: (Un)Install-Reihenfolge bei Dependencies

Beitrag von jub »

Ich habe mich letztendlich fuer Workaround 1 entschieden und setze vom Client aus per opsiServiceCall-Methode productOnClient_updateObjects die Attribute auf dem Depot-Server.

Bild

Der Nachteil dieser Loesung bleibt jedoch - wie schon erwaehnt - der hoehere Aufwand und die Einschranekung, dass der Uninstaller alle moeglichen Pakete, die man ausschliessen moechte, vom Client auch wirklich selbst entfernen kann.

Ein Vorteil: Es wird (zumindest bei meiner Realisierung) angezeigt, welches Paket fuer die Aenderung von Stand und Sollzustand verantwortlich war.
Antworten