Yngve Pettersen ist ein leitender Entwickler und Sicherheitsexperte, der von Anfang an bei Vivaldi dabei war. Mit seinem umfangreichen Hintergrund und seinem aufmerksamen Auge – und seiner großartigen Ausdrucksweise – ist er in der Lage, selbst komplexe Informationen klar zu erklären, selbst für diejenigen, die sich selbst vielleicht nicht als sehr technisch einschätzen.
Yngve, der Betreuer des Chromium-Codes von Vivaldi, hat kürzlich seinen Prozess zur Wartung eines Chromium-Forks auf seiner Vivaldi.net-Blog. Wir teilen es hier, falls Sie es verpasst haben.
(Hinweis: Dieser Artikel setzt voraus, dass Sie mit der Git-Terminologie, dem Erstellen von Chromium und verwandten Themen vertraut sind.)
Das Erstellen eines eigenen Chromium-basierten Browsers ist mit viel Arbeit verbunden, es sei denn, Sie möchten lediglich die Chromium-Basisversion ohne Änderungen ausliefern.
Wenn Sie an einem Chromium-basierten Browser arbeiten und diesen veröffentlichen möchten, benötigen Sie auf der technischen Seite einige Dinge, wenn Sie mit der ernsthaften Arbeit beginnen:
- Ein Git-Quellcode-Repository für Ihre Änderungen
- Eine oder mehrere Entwicklermaschinen, konfiguriert für jedes Betriebssystem, auf dem Sie veröffentlichen möchten
- Testmaschinen und -geräte zum Testen Ihrer Builds
- Baumaschinen für jede Plattform. Diese sollten mit einem System verbunden sein, das automatisch neue Test-Builds für jedes Quellupdate und Ihre Arbeitszweige sowie Produktions-Builds (offizielle Builds) erstellt. Diese sollten viel leistungsfähiger sein als Ihre Entwicklermaschinen. Offizielle Builds dauern selbst auf einer leistungsstarken Maschine mehrere Stunden und erfordern viel Arbeitsspeicher und Festplattenspeicher. Es sind verschiedene Cloud-Lösungen verfügbar, aber Sie sollten Zeit und (vor allem) Kosten sorgfältig abwägen. Ehrlich gesagt kostet ein eigenes Build-Server-Rack vor Ort vielleicht „etwas“ im Voraus, aber Sie haben dadurch eine bessere Kontrolle über das System.
- Eine Website, auf der Sie Ihre offiziellen Builds veröffentlichen können, damit Ihre Benutzer sie herunterladen und installieren können
Jetzt können Sie loslegen und mit der Entwicklung und Veröffentlichung Ihres Browsers beginnen.
Dann … veröffentlicht das Chromium-Team eine neue Hauptversion (was sie alle 4 oder 8 Wochen tun, je nach Strecke) mit vielen Sicherheitsfixes. Jetzt ist Ihr Browser fehlerhaft und unsicher. Wie bekommen Sie Ihre Fixes in die neue Version?
Dieser Vorgang kann sehr kompliziert und chaotisch werden, insbesondere wenn Sie viele Patches für den Chromium-Code haben. Diese führen häufig zu Zusammenführungskonflikten, wenn Sie den Quellcode auf eine neuere Chromium-Version aktualisieren, weil das Upstream-Projekt den von Ihnen gepatchten Code aktualisiert hat oder zumindest in der Nähe ist. Es gibt jedoch einige Dinge, die Sie dagegen tun können, um die Probleme zu reduzieren.
Es gibt mindestens zwei Hauptmethoden, um Aktualisierungen für eine Codebasis beizubehalten: einen Git-Zweig und Diff-Patches, die bei einem sauberen Checkout angewendet werden. Beide haben Vorteile und Herausforderungen, aber beide müssen regelmäßig aktualisiert werden, um mit dem Upstream-Code übereinzustimmen. Der unten beschriebene Prozess gilt für einen Git-Zweig.
Die Hauptregel besteht darin, Ihren gesamten (oder so viel wie möglich) zusätzlichen unabhängigen Code, also ganze Klassen und Funktionen (sogar zusätzliche Funktionen in Chromium-Klassen), in ein separates Repository-Modul zu legen, das den Chromium-Code als Untermodul enthält. Vivaldi verwendet spezielle Erweiterungen der GN-Projektsprache, um die relevanten Ziele mit den neuen Dateien und Abhängigkeiten zu aktualisieren.
Weitere Regeln für Patches sind:
- Fügen Sie alle hinzugefügten Includes/Importe *nach* der Upstream-Includes/Import-Deklaration ein.
- Gruppieren Sie auf ähnliche Weise alle neuen Funktionen und Mitglieder in Klassen am Ende des Abschnitts. Machen Sie dasselbe für andere Deklarationen.
- Alle Funktionen, die Sie einer Quelldatei hinzufügen müssen, sollten immer am Ende der Datei oder am Ende eines internen Namespaces eingefügt werden.
- Versuchen Sie grundsätzlich, über und unter Ihrem Patch eine leere Zeile einzufügen.
- Identifizieren Sie den Anfang und das Ende aller Ihrer Patches.
- Ändern Sie die Einrückung unveränderter Originalcodezeilen nicht, es sei denn, es ist unbedingt erforderlich (z. B. in Python-Dateien).
- Wiederholtes Patchen derselben Zeilen sollte korrigiert oder unterbunden werden. Solche Wiederholungen können während des Updates mehrere Zusammenführungskonflikte auslösen, die leicht zu Fehlern und Bugs führen können.
- Ändern Sie NIEMALS (ich wiederhole: NIEMALS!!!) die Chromium-String- und Übersetzungsdateien (GRD und XTB). Sie werden sich in große Schwierigkeiten bringen, wenn sich Strings ändern (und einige Tools können diese Dateien unter bestimmten Bedingungen durcheinanderbringen). Wenn Sie Strings überschreiben müssen, fügen Sie die Überschreibungen über Skripte hinzu, z. B. im Grit-System, indem Sie Ihre eigenen Änderungen mit denen des Upstreams zusammenführen (Vivaldi verwendet ein derart geändertes System; wenn genügend Interesse von Embeddern besteht, können wir es upstreamen; Sie finden die Skripte im Vivaldi-Quellpaket, wenn Sie sich damit befassen möchten).
Vivaldi verwendet (meistens) Git-Untermodule zur Verwaltung von Untermodulen und nicht das von Chromium verwendete DEPS-Dateisystem (einige Teile des Upstream-Quellcodes und der Tools von Vivaldi werden jedoch mit diesem System heruntergeladen). Unser Prozess zum Aktualisieren von Chromium funktioniert mit einigen Änderungen unabhängig vom verwendeten System.
Der erste Schritt des Prozesses besteht darin, zu identifizieren, in welches Upstream-Commit (U) Sie den Code verschieben möchten und welches das erste (F) und letzte (L, für das Sie einen Arbeitszweig W erstellen) Commit ist, das Sie über dieses Commit verschieben möchten. Wenn Sie aktualisierte Untermodule haben, tun Sie dies auch für diese.
(Es gibt verschiedene Möglichkeiten, den Arbeitszweig zu organisieren. Wir verwenden einen Zweig, der für jedes Update neu basiert. Eine andere Möglichkeit besteht darin, die Upstream-Updates in den von Ihnen verwendeten Zweig einzubinden. Dies wird jedoch schnell noch komplizierter als das Neubasieren von Zweigen, insbesondere bei größeren Updates. Nach zwei Jahren haben wir stattdessen mit dem Neubasieren von Zweigen begonnen.)
Der zweite Schritt besteht darin, das Upstream-U-Commit einschließlich der Untermodule auszuchecken. Wenn Sie Git-Untermodule verwenden, konfigurieren Sie diese in dieser Phase. Dieses Commit sollte als separates Commit behandelt und nicht in die Commits von F bis L aufgenommen werden.
Anschließend aktualisieren Sie die Untermodule mit allen Patches und aktualisieren die Commit-Referenzen.
Der resultierende Chromium-Checkout kann W_0 genannt werden.
Jetzt können wir anfangen, Patches auf W_0 zu verschieben. Der Git-Befehl dafür ist täuschend einfach:
git rebase –auf W_0 F~1 W
Dies wendet jedes Commit F bis L (einschließlich) nacheinander auf das Commit W_0 an und nennt den resultierenden Zweig W.
Bei einer Reihe dieser Commits (etwa 10 % der gepatchten Dateien in der Quellcodebasis von Vivaldi) treten beim Anwenden Zusammenführungskonflikte auf, und der Vorgang wird angehalten, während Sie die Konflikte beheben.
Es ist wichtig, die Konflikte sorgfältig zu prüfen und festzustellen, ob sie zu Funktionsstörungen führen können. Solche Möglichkeiten sollten Sie in Ihrem Fehlerverfolgungssystem registrieren.
Sobald die Rebase abgeschlossen ist (ein Vorgang, der mehrere Arbeitstage dauern kann), ist es Zeit für den nächsten Schritt: Lassen Sie den Code erneut erstellen.
Dies geschieht auf die gleiche Weise, wie Sie normalerweise Ihren Browser erstellen. Dabei werden auftretende Kompilierungsfehler behoben und alle Fehler registriert, die das Produkt möglicherweise beschädigen könnten. Auch dieser Schritt kann mehrere Arbeitstage dauern. Häufige Ursachen für Build-Probleme sind API-Änderungen und veraltete/umbenannte Header-Dateien.
Sobald Sie es erstellt und auf Ihrem Computer ausgeführt haben, ist es an der Zeit, (endlich) alle Ihre Änderungen zu übermitteln, den Arbeitszweig im obersten Modul zu aktualisieren und alles in Ihr Repository zu übertragen. Mein Vorschlag ist, dass Patches in Chromium meist als „Fixups“ des ursprünglichen Patches übermittelt werden. Dadurch wird das Konfliktpotenzial beim Zusammenführen verringert und Ihr Patch bleibt in einem Stück.
Versuchen Sie anschließend, es auf Ihren anderen Bereitstellungsplattformen zu kompilieren und beheben Sie dort etwaige Kompilierungsfehler.
Sobald Sie es erstellt haben und es vorzugsweise auf den anderen Plattformen ausführen, können Sie Ihre Autobuilder das Produkt für jede Plattform erstellen lassen und mit detaillierteren Tests beginnen, um die noch offenen Probleme und Regressionen zu beheben, die möglicherweise durch das Update verursacht wurden. Abhängig von der Komplexität Ihres Projekts kann dies mehrere Wochen dauern.
Dieser gesamte Ablauf kann automatisiert werden. Zusammenführungskonflikte und Kompilierungsfehler müssen Sie jedoch weiterhin manuell beheben sowie die resultierende ausführbare Datei testen und korrigieren.
Zum Zeitpunkt des Schreibens hat Vivaldi gerade Chromium 104 in unsere Codebasis integriert, ein Prozess, der etwas mehr als zwei Wochen gedauert hat (der Prozess kann manchmal länger dauern). Vivaldi verwendet nur die Extended Stable-Releases von Chromium im 8-Wochen-Zyklus, da die Aktualisierung der Codebasis und die anschließende Stabilisierung des Produkts Zeit erfordern. Unserer Meinung nach können Sie den 4-Wochen-Zyklus nur einhalten, wenn Sie bei einer erheblichen Anzahl von Patches mindestens zwei vollständige Teams für Upgrades und Entwicklung haben. Sehr wahrscheinlich muss der Upgrade-Prozess wöchentlich auf die neueste Dev- oder Canary-Version aktualisiert werden.
Sobald Sie Ihren Browser alle paar Wochen in Produktion bringen, werden Sie auf ein etwas anderes Problem stoßen: den Browser mit den (Sicherheits-)Patches auf dem neuesten Stand zu halten, die auf die Upstream-Version angewendet werden, auf der Ihr Fork basiert. Das bedeutet wiederum, dass Sie die Codebasis aktualisieren müssen, aber diese Änderungen sind normalerweise nicht so umfangreich wie bei einem Hauptversions-Upgrade. Eine leicht modifizierte, weniger komplizierte Variante des obigen Prozesses kann verwendet werden, um solche kleineren Versionsupdates durchzuführen, und in unserem Fall dauert dieser kleinere Prozess normalerweise nur ein paar Stunden.
Viel Glück mit Ihrem brandneuen Browser-Fork!
Weitere Informationen und Einblicke von Yngve finden Sie in seinem Blog. Yngves Eckeauf Vivaldi.net.
Haben Sie eine Frage oder möchten Sie etwas hinzufügen? Lassen Sie es uns in den Kommentaren wissen!
