versionierte Abhängigkeiten

[feltel]

Ich bin gerade dabei mir die Welt von OPSI zu erarbeiten und ich find das ganze System schick und nützlich. Großes Lob von mir. Ich würde mir bezüglich der Paketabhängigkeiten noch ein Feature wünschen. Und zwar hab ich aktuell ein kleines Problem, das damit automatisch lösbar wäre.

Ich habe auf einigen Maschinen iTunes verteilt und aus Gründen der Paketgröße und Wiederverwendbarkeit den Part "Apple Application Support" in ein eigenes Paket ausgegliedert, da dieser Teil auch z.B. von QuickTime, iCloud usw. genutzt wird. Apple hat mit dem aktuellen iTunes-Release das x64-Paket komplett auf x64 umgestellt, mit dem Effekt das ebenso das Apple Application Support-Paket aktualisiert werden muss. Setze ich jetzt das neue iTunes-Paket auf setup, dann ist ja für den Configed die Abhängigkeit zu Apple Application Support erfüllt, da es bereits installiert ist; jedoch in einer alten Version, die für das neue iTunes-Paket nicht tauglich ist.

Ich würde mir also bei den Paketabhängigkeiten wünschen, dass ich dort neben dem Paketnamen auch eine Version angeben kann, die dieses Paket mindestens haben muss, damit die Abhängkeiten erfüllt sind.

So in der Art hier:

Code: Alles auswählen

[Package]
version: 1
depends: 
incremental: False

[Product]
type: localboot
id: itunes
name: iTunes
description: Apple iTunes
advice: 
version: 12.1.0.71
priority: 0
licenseRequired: False
productClasses: 
setupScript: _install.ins
uninstallScript: _uninst.ins
updateScript: 
alwaysScript: 
onceScript: 
customScript: 
userLoginScript: 

[ProductDependency]
action: setup
requiredProduct: apple-application-support (>=3.1.1-1)
requiredStatus: installed
requirementType: before

[Changelog]
itunes (12.1.0.71-1) stable; urgency=low

 * new upstream release

 -- Sebastian Feltel <sebastian.feltel@docemus.de> Wed, 04 Feb 2015 14:20:52 + 0100

itunes (12.0.1.26-1) stable; urgency=low

 * new upstream release

 -- Sebastian Feltel <sebastian.feltel@docemus.de> Mon, 26 Jan 2015 10:30:11 + 0100

itunes (1.0-1) stable; urgency=low

  * Initial version

 -- Sebastian Feltel <sebastian.feltel@docemus.de> Fri, 23 Jan 2015 10:01:19 + 0100

[pandel]

+1, was uns vor allem auf dem Weg zu einer ausgewachsenen Release-basierten Paketverwaltung wieder einen Schritt weiter brächte

[n.wenselowski]

Hallo,

ich habe das mal als Ticket aufgenommen, weil ich es auch für einigermaßen sinnvoll halte.
Problematisch könnte sowas allerdings dann werden, wenn bestimmte Versionen angefordert werden kann, die der Depotserver nicht mehr liefern kann, weil mittlerweile eine neuere Version zur Verfügung steht. Wir wollen nie alte, sondern immer die neueste Version mit opsi verteilen und stellen deshalb auf dem Depot immer nur eine Version (idR die neueste) bereit.

Als Workaround kann ich mir momemtan folgendes vorstellen:

• Requirement so abändern, dass immer ein Setup angefordert wird.
• Im Code mittels opsiservicecall überprüfen, ob die installierte Version aktuell genug ist und im Fehlerfall das Script entweder abbrechen oder die Installation einer neueren Version anfordern
• Dafür sorgen, dass die Version des Frameworks auf den Clients immer aktuell ist
• Ein Produkt für jede unterschiedliche Version erstellen (finde ich aber nicht nur aufwändig, sondern generell eher hässlich)

Gruß

Niko

[pandel]

Wir wollen nie alte, sondern immer die neueste Version mit opsi verteilen und stellen deshalb auf dem Depot immer nur eine Version (idR die neueste) bereit.

Warum?

Gesetz den Fall, es gäbe eine Bündelung:

Release A (1.0)

• Software 1, v1.0
• Software 2, v1.0
• Software 3, v1.0

Release B (1.1)

• Software 1, v1.0
• Software 2, v1.2
• Software 3, v1.3

Wenn ich dann für einen Client Release A anfordere, wäre bezogen auf das Bündel, alles passend aktuell und gleichzeitig, wenn ich Release B für einen anderen Client anfordere, müsste ich "Software 1" nur einmal vorhalten. Immer nur die neueste Software zu nehmen ist im Rahmen komplexerer Konfigurationen, wo Software versionsseitig aufeinander abgestimmt sein muss, nicht immer der Weisheit letzter Schluss.

Und wie du selbst geschrieben hast:

Ein Produkt für jede unterschiedliche Version erstellen (finde ich aber nicht nur aufwändig, sondern generell eher hässlich)

... das ist DEFINITIV hässlich... aber leider momentan nötig...