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
Veraltete Paketabhängigkeiten führen zu Fehlern
Moderators: MVogt, moderators
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.
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.
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.
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.
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.
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.
Nein, tut er nicht, weil wir das alte Paket in ein anderes Register "Alte Software" verschieben. Damit können die Namen auch gleich bleiben.Dann muss es doch eigentlich einen anderen Namen haben, da ansonsten der Configurator meckert, weil das Objekt bereits existiert.
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".
"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.Wir kopieren das vorhandene Paket, um sofort alle definierten Eigenschaften (z.B. Abhängigkeiten) zu übernehmen:
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".
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!!
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!!
Who is online
Users browsing this forum: No registered users and 5 guests