Veraltete Paketabhängigkeiten führen zu Fehlern

Moderators: MVogt, moderators

Post Reply
Bela
Posts: 78
Joined: 04. Jan 2005, 11:15
Contact:

Veraltete Paketabhängigkeiten führen zu Fehlern

Post by Bela » 12. Sep 2006, 14:20

Hallo zusammen,

folgendes ist mir heute aufgefallen:

Es wird eine Versionsunabhängigkeit in den Abhängigkeiten bei den Paketeigenschaften vorgetäuscht, die jedoch nicht vorhanden ist. Empirum speichert intern noch zuätzlich die Versionsnummer der Requirements mit ab (was später zu Fehlern führt), zeigt dies aber nicht an!

Beispiel:

"Software A" 2.0 benötigt "Software B" 1.0 als Installationsvoraussetzung. Deshalb wurde bei "Software A" unter den Paketeigenschaften unter Version eine Abhängigkeit definiert. Das funktioniert auch.

Nun hat sich die Version von "Software B" auf 2.0 geändert, der Paketname ist natürlich gleich geblieben. An der Abhängigkeit hat sich nichts geändert. Jetzt wird "Software A" aber nicht mehr installiert, da anscheinend die Definition der Abhängigkeit sich nicht nur auf den Paketnamen sondern auch auf die Version bezieht - nur ist das nirgends sichtbar! Schaut man in die Paketeigenschaften von "Software A" steht da lediglich 'Requirements "Software B" ' und kein Hinweis auf die Versionsnummer. Beim Installieren meldet das Softwaredepot dann jedoch "Fehlende Installationsvoraussetzung: Software B\1.0".
Man muss also "Software B" in der Abhängigkeitsdefinition löschen und "Software B" wieder hinzufügen... sehr unschön.

Wie kann man das Problem elegant lösen, ohne die Eigenschaften von den Paketen zu ändern bzw. wie geht man vor, wenn sich Versionen von Paketen ändern, die Voraussetzungen für andere sind?


Bela Pörenyi

Heumer
Posts: 16
Joined: 15. Dec 2004, 08:05
Contact:

Post by Heumer » 12. Sep 2006, 15:54

Hallo,

wie haben Sie im Configurator die Version der "Software B" geändert? Wichtig ist auch, dass der sogenannten Maschinenkeyname in der Datenbank (Tabelle Software) mit abgeändert wird, der auch die Version enthält. Sie erreichen dies, indem Sie im Configurator unter "Extras" die Funktion "Versionen abgleichen" ausführen.

Hierbei erfolgt für alle Pakete ein Abgleich zwischen der Datenbank und den Paketen auf Fileebene (also Setup.inf). Auch der Maschinenkeyname wird bei Versionsveränderung neu geschrieben.

Bela
Posts: 78
Joined: 04. Jan 2005, 11:15
Contact:

Post by Bela » 12. Sep 2006, 16:29

Hallo,

danke für die Antwort. Unsere aktuelle Software ist im Register "Software" untergebracht. Wird eine Version der Software erhöht, wandert die alte Version in ein Register "Alte Software", damit sie noch zum Testen etc. zur Verfügung steht. Die neue Version wird ganz normal mit "Paket einfügen..." in das Register "Software" eingefügt. Deswegen bringt ein anschließendes "Versionen abgleichen" auch keine Meldung, weil die Einträge in der Setup.inf mit den Einträgen in der Empirum-Datenbank übereinstimmen (altes Paket hat aktuelle Daten seiner Setup.inf in der Datenbank, das neue Paket durch das neu Hinzufügen auch).

"Versionen abgleichen" benutzen wir eigentlich nur bei einer Revisionserhöhung. Die hat jedoch keinen Einfluß auf die Abhängigkeiten.

Heumer
Posts: 16
Joined: 15. Dec 2004, 08:05
Contact:

Post by Heumer » 12. Sep 2006, 17:16

Sie schreiben, dass Sie das Paket neu Hinzufügen. Dann muss es doch eigentlich einen anderen Namen haben, da ansonsten der Configurator meckert, weil das Objekt bereits existiert.

Wir gehen bei Versionserhöhungen folgendermaßen vor (auch dann wenn das neue Paket als abhängiges Paket in anderen Paketen eingefügt wurde):

Wir kopieren das vorhandene Paket, um sofort alle definierten Eigenschaften (z.B. Abhängigkeiten) zu übernehmen:
Beispiel "Software B\1.0" wird zu "Software B\1.0(2)". Das kopierte Paket wird nun angepasst es heisst dann "Software B\2.0" (Wenn es sich denn um die Version 2.0 handelt). Im Configurator gibt es nun also die beiden Pakete: "Software B\1.0" und "Software B\2.0".

Für das neue Paket "Software B\2.0" bilden wir übergangsweise eine Softwaregruppe mit gleichem Namen und nehmen Testrechner auf.

Wenn das Testverfahren abgeschlossen ist, löschen wir im Configurator das Paket "Software B\2.0" und passen das noch vorhandene Paket "Software B\1.0" so an, dass die Version und der Name geändert wird. Es gibt dann also nur noch das Paket "Software B\2.0". Vorteil bei dieser Vorgehensweise ist, dass automatisch alle Rechner upgedatet werden, die bis zu diesem Zeitpunkt die Software "Software B\1.0" zugewiesen hatten, und zwar ohne neue Paketzuweisung. Damit das ganze auch so funktioniert machen wir dann noch über "Versionen abgleichen" den Abgleich mit der Setup.inf.

Bela
Posts: 78
Joined: 04. Jan 2005, 11:15
Contact:

Post by Bela » 12. Sep 2006, 18:14

Dann muss es doch eigentlich einen anderen Namen haben, da ansonsten der Configurator meckert, weil das Objekt bereits existiert.
Nein, tut er nicht, weil wir das alte Paket in ein anderes Register "Alte Software" verschieben. Damit können die Namen auch gleich bleiben.
Z.B. "Adobe Reader" heisst auch in neuer Version "Adobe Reader", denn Versionsnummern haben in der Bezeichnung nichts zu suchen. Nur befindet sich der alte "Adobe Reader" im Register "Alte Software" und der neue "Adobe Reader" im Register "Software".
Wir kopieren das vorhandene Paket, um sofort alle definierten Eigenschaften (z.B. Abhängigkeiten) zu übernehmen:
"Software B" hat selber keine Abhängigkeiten definiert! Es geht ja hier um "Software A"! Diese bezieht sich eben nach einer Versionsänderung von "Software B" eben leider noch auf die Version 1.0 anstatt auf die Version 2.0! Egal, auf welchem Weg man "Software B" auch ändert... doch wird zum einen das nicht angezeigt (Configurator-->Depot-->Register-->Paket --> bei Requirements steht nur der Name des Paketes "Software B", nicht die Version! Aber die ist anscheinend trotzdem mit in der Datenbank abgespeichert!) Und zum anderen sollte eben automatisch die letzte Version eines Paketes zur Prüfung der Abhängigkeit genommen werden, was eben nicht funktioniert.

Szenario:
"Software B" 2.0 wird installiert. Wird anschließend "Software A" installiert und ist "Software B" 1.0 nicht installiert, kommt es zum Abbruch. Das SoftwareDepot prüft immer noch auf die Version 1.0 von "Software B" (weil die Abhängigkeit zum Zeitpunkt von 1.0 definiert wurde). Und in den Paketeigenschaften von "Software A" bei Abhängigkeiten steht nichts von "Software B" mit Version 1.0... sondern eben nur "Software B".

Heumer
Posts: 16
Joined: 15. Dec 2004, 08:05
Contact:

Post by Heumer » 13. Sep 2006, 08:36

Hallo,

also ich habe es gerade noch einmal ausprobiert und mir testweise zwei neue Register angelegt "Alte Software" und "Software".
Dann habe ich im Register "Alte Software" das Paket "Adobe Reader" erstellt. Beim Versuch dieses mit gleichem Namen im Register "Software" anzulegen erhielt ich den Fehler: 'Ein Objekt mit dem Namen 'Adobe Reader' existiert bereits. Bitte geben Sie einen anderen Namen ein.'

Meiner Meinung nach auch völlig richtig. Anhand des Namens wird doch ein Paket identifiziert! Ein Paket kann damit im Depot nur einmal vorkommen. Aber das nur am Rande.

Thema Abhängigkeiten:
Es ist richtig, dass die Version bei einer definierten Abhängigkeit nicht angezeigt wird. Natürlich ist diese jedoch in der Datenbank gespeichert und wird bei Veränderung auch mit abgeändert!! Dies kann wunderbar in der Empirum-Datenbank (Tabelle SWDependencies) verfolgt werden.
Jedes Softwarepaket ist in der Tabelle Software mit einer ID hinterlegt. In der Tabelle SWDependencies werden die Abhängigkeiten definiert.

Um nun zu erreichen, dass das Paket (in dem Beispiel "Software B"), welches in anderen Paketen als Abhängigkeit eingetragen ist mit aktualisiert wird, müssen Sie genau dieses Paket (Software B) anpassen. Wenn Sie hier die Version erhöhen, wird das in allen Paketen, in dem es als abhängiges Paket eingetragen ist, berücksichtigt. Wenn Sie es allerdings neu hinzufügen, erhält es eine völlig neue SoftwareID in der Datenbank und müsste auch neu als abhängiges Paket in den anderen Paketen eingetragen werden!!

Post Reply

Return to “Software Management”

Who is online

Users browsing this forum: No registered users and 5 guests