Ok, sehr dramatischer Titel, ich gebs zu 🙂 Gitolite kennt der ein oder andere Entwickler sicher, weil man damit auf seinem eigenen Server Git Repos nutzen kann, was auch gern benutzt wird.

g..g..gi…gi..git…gitolite!

Nun ist gitolite keine neue Erfindung, sondern schon eine Weile alt. So alt, daß es schon seit 2017 gitolite3 gibt. Gitolite(2)  wurde dagegen eingestellt, weil es EOL hatte. Fedora stellt daher dafür keine Pakete mehr zur Verfügung und installiert ersatzweise gitolite3.

„Das ist blöd!“ stellten wir nach einem Serverupgrade fest, da das Paket gitolite(2) beim Löschen 6 GB Projektdaten mit ins Nirvana gezogen hatte, da diese im Homedir liegen.. dachten wir. Zum Glück hatten wir eine Anpassung für Chroots gemacht, so daß nur der Link auf das Homedir gelöscht wurde, aber die Daten noch in der Chroot lagen. Wir hätten natürlich auch ein Backup gehabt, aber so war es noch einfacher.

„Bekomme es wieder zum Laufen…“

Etwas schwieriger gestaltete sich die Reinstallation unter Fedora 31, da sich zwischenzeitlich Perl von 5.28 auf 5.30 geändert hatte, und gitolite Paket aber unbedingt 5.28 haben wollte. Nun ja, Perl 5.30 zu entfernen kam nicht in Frage, also riskierten wir es und installierten gitolite ohne Abhängigkeiten:

rpm -i –nodeps https://kojipkgs.fedoraproject.org//vol/fedora_koji_archive04/packages/gitolite/2.3.1/18.fc29/noarch/gitolite-2.3.1-18.fc29.noarch.rpm

Zum Glück funktioniert gitolite 2.3.1 auch mit Perl 5.30 bislang ohne Fehler, so daß erstmal weiter gearbeitet werden kann. Es ist nämlich durchaus ein mächtiges Stück Arbeit, von Gitolite2 auf Gitolite3 umzusteigen, wie die Migrationsanweisung zeigt. Daher hat der Betroffene nun gleich Gitlab ins Auge gefasst. Mal sehen wie das wird 😉