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

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 😉