Fehler beim Update --> WSC erkennt beim Update nicht ein schon Installiertes Paket

  • Nach meinen Feststellungen ist es dem WSC nicht möglich, während eines Updates ein schon vorhandenes Paket (welches gerade installiert wurde) erneut zu erkennen.


    Folgendes wurde durchgeführt:


    Vor dem Update der Version WCF 2.1.16 und WBB 4.1.15 habe ich zwei Pakete, die noch nicht das gleiche Paket als Abhängigkeit nutzen.


    Nach dem Update auf die WSC Version 3.0.6 (und WBB 5.0.6) wurde zuerst Paket 1 (VieCode Shop) auf die neue Version ohne Probleme geupdatet. Dabei wurde auch ein requirement Packet (de.softcreatr.wsc.fontAwesomeUtils) mit installiert.

    Als das Update soweit durch war vom VieCode-Shop wurde nun der Bugtracker geupdatet.


    Dieser hat auch das gleiche Paket als requirement. Nun kommt beim Update folgende Fehlermeldung:


    Requested URL
    /acp/index.php?install-package/&&
    Referrer
    http://www.mdman.de/acp/index.php?package-update/&
    Error Message
    A package can't overwrite files from other packages. Only an update from the package which owns the file can do that. (Package 'de.softcreatr.wsc.fontAwesomeUtils' tries to overwrite file 'js/SoftCreatR/FontAwesome.js', which is owned by package 'de.softcreatr.wsc.fontAwesomeUtils')
    Type
    wcf\system\exception\SystemException
    File (Line)
    /var/www/vhosts/mdman.de/httpdocs/wcf/lib/system/package/FilesFileHandler.class.php (43)
    Stacktrace
    1. /var/www/vhosts/mdman.de/httpdocs/wcf/lib/system/setup/Installer.class.php (183): wcf\system\package\FilesFileHandler->checkFiles(…)
    2. /var/www/vhosts/mdman.de/httpdocs/wcf/lib/system/setup/Installer.class.php (144): wcf\system\setup\Installer->checkFiles(…)
    3. /var/www/vhosts/mdman.de/httpdocs/wcf/lib/system/setup/Installer.class.php (54): wcf\system\setup\Installer->install(…)
    4. /var/www/vhosts/mdman.de/httpdocs/wcf/lib/system/package/PackageInstallationDispatcher.class.php (690): wcf\system\setup\Installer->__construct(…)
    5. /var/www/vhosts/mdman.de/httpdocs/wcf/lib/system/package/plugin/FilePackageInstallationPlugin.class.php (50): wcf\system\package\PackageInstallationDispatcher->extractFiles(…)
    6. /var/www/vhosts/mdman.de/httpdocs/wcf/lib/system/package/PackageInstallationDispatcher.class.php (603): wcf\system\package\plugin\FilePackageInstallationPlugin->install(…)
    7. /var/www/vhosts/mdman.de/httpdocs/wcf/lib/system/package/PackageInstallationDispatcher.class.php (141): wcf\system\package\PackageInstallationDispatcher->executePIP(…)
    8. /var/www/vhosts/mdman.de/httpdocs/wcf/lib/acp/action/InstallPackageAction.class.php (72): wcf\system\package\PackageInstallationDispatcher->install(…)
    9. /var/www/vhosts/mdman.de/httpdocs/wcf/lib/action/AbstractDialogAction.class.php (68): wcf\acp\action\InstallPackageAction->stepInstall(…)
    10. /var/www/vhosts/mdman.de/httpdocs/wcf/lib/action/AbstractAction.class.php (47): wcf\action\AbstractDialogAction->execute(…)
    11. /var/www/vhosts/mdman.de/httpdocs/wcf/lib/system/request/Request.class.php (83): wcf\action\AbstractAction->__run(…)
    12. /var/www/vhosts/mdman.de/httpdocs/wcf/lib/system/request/RequestHandler.class.php (94): wcf\system\request\Request->execute(…)
    13. /var/www/vhosts/mdman.de/httpdocs/acp/index.php (9): wcf\system\request\RequestHandler->handle(…)

    Das WSC versucht hier das gleiche Paket noch mal zu installieren. Das kann so nicht richtig sein. Es sollte eigentlich vor dem Install erst erneut schauen, ob die Abhängigkeiten schon gelöst wurden. Anscheinend schaut das WSC nur ganz am Anfang des Update-Prozesses in die Abhängigkeiten und versucht dann unter Umständen öfters das gleiche Paket mehrmals zu installieren.


    Hier sollte man die Update-Routine anpassen und vor jeder Install eines Paketes die Abhängigkeiten erneut überprüfen.


    Hier auch mal ein Video des Update-Versuches:


    screencast.com/t/ptTfL0H2cYd


    Im Anhang ein Bild von der Paketliste vor dem Update-Versuch.

  • Ich hatte das Problem schon bei mehreren Kunden. Das Problem tritt auf, wenn mehrere Pakete ein Requirment auf ein Paket haben, welches noch nicht installiert ist, aber unterschiedliche Versionsnummern voraussetzen. z.B.:

    • Paket A hat als requiredPackage R in der Version 1.0.0
    • Paket B hat als requiredPackage R in Version 1.0.1

    Das WCF 2.1 (und wahrscheinlich tritt das Problem auch bei der Suite auf) erkennt nun beim gleichzeitigen Update von Paket A und B, dass Abhängigkeit R noch nicht installiert ist. Das Problem liegt aber darin, dass nicht erkannt wird, dass es sich unterschiedliche Version handelt und nur Paket R in Version 1.0.1 installiert werden muss. Das WCF versucht fälschlicherweise Paket R nun in Version 1.0.0 und 1.0.1 zu installieren. Durch die doppelte Installation gibt es nun den oben genannten Fehler. In der Paketliste scheint dann auch Paket R zwei mal auf.

    • Official Post

    Ich habe es jetzt mal mit entsprechenden Paketen ausprobiert, die beide ein gemeinsames Paket, aber in unterschiedlicher Version, als Abhängigkeit haben. Im Endeffekt wurde das Paket in der höchsten Version nur einmal installiert, das war in der Form auch im Installation-Stack so erkennbar.


    Mich wundert es deshalb, weil in \wcf\system\package\PackageInstallationScheduler in der Methode tryToInstallPackage() explizit auf $this->virtualPackageVersions zugegriffen wird. In diesem Array werden alle Pakete getracked, die im weiteren Verlauf installiert oder aktualisiert werden sollen.


    Sollte einer von euch noch eine entsprechende Installation haben bei der es reproduzierbar ist: Wenn Ihr nach Zeile 68 ein die("<pre>".print_r($this, true)); einfügt, erhaltet ihr beim Update-Versuch einen entsprechenden Dump des gesamten Stacks. Diese Angaben würden mir ungemein weiterhelfen, da dort der exakte Ablauf inklusive der Ausgangsbedingungen ablesbar ist. Es kommt zwar zum Download der Updates (ggf. inklusive Abfrage der Zugangsdaten), aber das eigentliche Update wird nicht durchgeführt. Achtung: Die Ausgabe kann sensible Informationen (z. B. gespeicherte Passwörter von Update-Servern) enthalten, bitte entfernt diese!


    Als ich das Update durchgeführt hatte, war ja schon die Suite in der Version 3.0.6 installiert gewesen und dann kam ja erst das Update von den anderen Paketen.

    Nein, der gesamte Stack wird vor dem Update angelegt und wird danach nicht mehr verändert.

    • Official Post

    EDIT: Alexander Ebert : Ich habe mal eine EMail mit allen nötigen Informationen an support@woltlab.com geschickt... ;)

    Bitte nicht! Die E-Mail-Adresse wird nur vom Ticket-System genutzt und jede die E-Mail die nicht zu einem Ticket gehört wird verworfen. Anders gesagt: Was auch immer du geschickt hast, es befindet sich nun im Daten-Nirvana :P


    Entweder an ebert@woltlab.com oder woltlab@woltlab.com

    • Official Post

    An dieser Stelle erstmal ein Danke an MDMAN für die zur Verfügung gestellte Sicherung!


    Zum eigentlichen Thema: Ich konnte es auch mit dieser Sicherung nicht reproduzieren, selbst nachdem ich durch Datenbank-Veränderung sowohl den Bugtracker auf 3.0.0 als auch den VieCode-Shop auf 7.0.0 begrenzt habe. Ich habe zusätzlich auch den genauen Vorgang bei der Berechnung der Abhängigkeiten protokollieren lassen. Die genannten FontAwesome Utils tauchten dort im Verkauf zwar mehrfach auf, am Ende wurden die Versionen aber korrekt aufgelöst und nur die höchste verfügbare Version installiert (1.1.1 pl 3).


    Ich kann natürlich nicht ausschließen, dass ich irgendein anderes Update übersehen habe bzw. es zum Zeitpunkt deiner Durchführung andere Abhängigkeiten bestanden haben. Mit dem aktuellen (respektive dem manuell angepassten) Stand kann ich es jedenfalls nicht reproduzieren.


    VieCode Ich bin mir gerade nicht sicher, ob dies mit der Version 7.0.1 korrigiert ist, aber bei dem Update von 6.2 auf 7.0.0 trat folgender Fehler auf:

    SQL
    ALTER TABLE shop1_order CHANGE invoiceIdentifier invoiceIdentifier VARCHAR(191) NOT NULL;
    
    --
    -- Warning: 1265 Data truncated for column 'invoiceIdentifier' at row 1
    --


    Um dieses Problem zu umgehen, führen wir zwei Abfragen hintereinander aus, etwa so:

    SQL
    UPDATE wcf1_acl_option SET optionName = SUBSTRING(optionName, 1, 191);
    ALTER TABLE wcf1_acl_option CHANGE optionName optionName VARCHAR(191) NOT NULL;


    Falls das Problem mit der Version 7.0.1 bereits korrigiert sein sollte, so ignorier mich einfach ;)

  • Das Problem wurde schon korrigiert...


    Alexander Ebert : Hattest du denn beim Update die alte Version 7.0.0 vom VieCode - Paketserver geladen, oder hast du nur die Versionsnummer manipuliert?


    Derzeit ist nur noch die neuere Version 7.0.1 und eine korrigierte Version 3.0.0 vom Bugtracker online... da sind beide Versionen vom FontAwesome Utils auf die Version 1.1.1 pl 3 gebracht worden... vorher war beim Shop eine andere Version als requirement als beim Bugtracker.


    Eventuell solltest du mal eine angepasste package.xml vom Shop und Bugtacker verwenden, der dann die Version 1.1.1 vom FontAwesome Utils verlangt und der Bugtracker dann die Version 1.1.0...



    EDIT sagt: Peter hat zum Testen mal die Version 7.0.0 RC 3 wieder in seinem Paketserver aktiviert. Damit sollte dann das Problem wieder erscheinen...

    • Official Post

    Welche Updates am Ende angefordert werden, ist einzig und alleine von den Daten in den wcf1_package_update*-Tabellen abhängig, dort habe ich die 7.0.1er Version entfernt. Zusätzlich habe ich bei den Abhängigkeiten (wcf1_package_update_requirement) feststellen können, dass der Bugtracker und der Shop unterschiedliche Versionen der FontAwesome Utils benötigten.

  • In den aktuell angebotenen Versionen ist anscheinend der Versionsstand (Shop 7.0.1) und Bugtracker (3.0.0) gleich.


    Ich schätze mal, dass der Bugtracker eine kleinere Version angefordert hatte als der Shop. Und darum wollte das WCF die Version einfach neu installieren, statt ein Update durchzuführen.


    Ich denke, der Shop wollte ursprünglich die Version 1.1.0 installieren und als dann der Shop mit dem AwesomeIcon Util installiert wurde kam anschließend erst der Bugtracker. Der hatte dann die Version 1.0.0 (oder auf alle Fälle kleinere Version) als Voraussetzung. Da gibt es logischerweise keine Update-Anweisung zur schon installierten Version 1.1.0 und ich denke darum will das WCF die 1.0.0 nochmals neben der 1.1.0 installieren.


    Darum die Fehlermeldung, dass er die Version nicht aktualisieren kann.


    Vielleicht hilft ja das hier bei der Fehlersuche auch etwas weiter:


    screencast.com/t/ptTfL0H2cYd

  • Nach einer Rückfrage habe ich folgende Infos noch mal zu diesem Problem:


    Alexander Ebert :

    Der Bugtracker in der Version 3.0.0 wurde mit Version 1.1.1 des FontAwesome Utils mitgeliefert. Nun wurde er in der Version 3.0.0 angepasst und liefert die Version 1.1.1 pl 3 mit. Darum will das WCF hier kein Update mehr fahren.


    Der Shop hat damals denke ich mal die Version 1.1.0 oder dergleichen mitgeliefert... Das WFC wollte dann nachdem es die Install beendet hatte vom Shop und vom FontAwesome-Plugin dieses mit der Version 1.1.1 vom Bugtracker überschreiben. Dabei wird es wohl nicht erkannt haben, dass es das gleiche Plugin ist, denn die Fehlermeldung sagt ja, es handelt sich um ein Fremdes Plugin.


    Vielleicht hilft das ja nun bei der Fehlersuche. Auf alle Fälle sind nun die Versionen am Paketserver auf die gleiche Version 1.1.1 pl 3 angeglichen worden! Ein Reproduzieren kann nur mit alten Paketen erfolgen indem man eigene Paketserver aufsetzt und es dann mit den entsprechenden vorherigen Versionen der Plugins testet.


    Gruß