In der Abhängigkeitshölle des CPAN

Das Comprehensive Perl Archive Network (CPAN) war seinerzeit eine Revolution [1] und ist auch heute noch Quelle vieler Inspirationen, schließlich bedient sich seit über zehn Jahren auch Perlmeister Mike Schilli aus seinem Fundus. In dieser Ausgabe geht es um einen IRC-Client in Perl. Neben den Software-Fragmenten, die Perl-Anhängern den reichen Schatz an vorgefertigten Teillösungen bescherten, waren es aber Neuerungen wie die Abhängigkeitsauflösung und die CPAN-Shell, die die wirkliche Revolution bedeuteten.

Die Tex-Community hatte schon seit Anfang der 1990er Jahre im CTAN Code nach einer zentralen Systematik gesammelt [2]. Im Oktober 1995 zog dann der Finne Jarkko Hietaniemi für Perl nach und eröffnete das CPAN. Neu waren einheitliche Dokumentation sowie Installations- und Testroutinen nach einem festgelegten Schema. Mit dem CPAN-Modul von Andreas König folgte bald auch ein Werkzeug, um in der wachsenden Fülle zu suchen, Pakete herunterzuladen und zu installieren. Heute enthält das CPAN über 16000 Module mit rund 20 Millionen Zeilen Code, sodass die knapp 4 GByte Daten eines der größten kohärenten Software-Archive bilden.

Verworren groß

Damit wurde es geistiger Vater vieler anderer Paketsysteme, etwa von Ruby Gems oder des PHP-Archivs PEAR. Selbst Distributionen wie Debian oder die RPM-Derivate haben sich die eine oder andere Idee vom CPAN abgeschaut. Doch damit fingen die Probleme auch an. Wie soll sich ein Paketsystem, das viele Dateien und ihre Abhängigkeiten verwaltet, in einen weiteren Softwaremanager einer Distribution einbinden? Für Debian gibt es über 1000 Perl-Pakete, von denen viele direkt einem CPAN-Modul entsprechen, doch was ist mit den übrigen 15000? Da gibt es zwar das Hilfsskript »dh-make-perl« der Debian Perl Group [3], doch selbst Experten geben zu, dass Handarbeit angesagt ist, sobald Module Standardpfade verlassen.

Kannibalische Vielfalt

So bleibt dem Sysadmin die Wahl zwischen Pest und Cholera: Entweder er verwaltet seine Perl-Module, wie es das CPAN vorgesehen hat, und verletzt dann seine Datei-Integrität bei Debian oder Co. oder er muss aufwändig Distributionspakete bauen, verwalten und aktualisieren. Das ist aber gar nicht so einfach. Wer einmal Code mit Hilfe eines Perl-Moduls geschrieben hat, möchte es ungern aktualisieren, wenn umfangreiche eigene Projekte es verwenden.

Dazu kommt, dass bei ihrer Größe eine unübersichtliche Vielfalt an ähnlichem Code in der Bibliothek steht. So gibt es diverse Datums-Konvertierer, zig E-Mailer und einige XML-Parser - jeder mit inkompatibler Aufrufsemantik. Wer eine Anwendung mit Perl betreiben möchte, hat schnell Dutzende Abhängigkeiten am Hals, deren Pflege zum Fluch werden kann. Vielleicht bekommen die Perl-Entwickler ja mit Blick auf andere Repositories noch den Bogen und verschaffen so ihren Anwendern Erleichterung aus der Dendency Hell.