Als am Freitag Berichte über »Vorkommnisse« bei Blastwave, einem beliebten Repository für precompiled Solaris-Binaries, die Runde machten, war ich erst amüsiert. Daß der Domain- und Namensrechteinhaber schon in der Vergangenheit Leute ausgesperrt haben soll, die sein AAL-Modell erst erfolgreich gemacht haben – AAL (Andere arbeiten lassen) geht nicht mehr so gut, wenn man den Anderen die Möglichkeit zur Arbeit nimmt –, das klingt zu popcornlastig um wahr zu sein.
In der heutigen Zeit empfinde ich es zunehmend lästig, daß ich unter Solaris mir Software meist selbst besorgen, selbst übersetzen und die Installation auch noch selbst verwalten muß; unter Linux mache ich nur noch seltenst den »configure; make; make install«-Dreisatz. Daß apt-get bzw. yum kein Ergebnis bringen, ist unter Red Hat/Fedora, erst recht aber unter Debian, die große Ausnahme (patentproblembeladene Multimedia-Themen einmal außen vor gelassen) und die Nutzung der paketierten Software ermöglicht erst eine sinnvolle Versionierung und ggf. auch ein Downgrading einzelner Pakete. Das alles geht Sun Solaris eher so ab, zumindest beim bis Solaris 9 aktuellen Packaging Subsystem. Blastwave und pkg-get schienen da ein Weg zu sein, auch dem gemeinen Entwickler das Leben zu erleichtern.
Und nun streiten sich Projektinitiator und Projektarbeiter?
Hintergrund der Aktion waren jedoch Streitigkeiten über die generelle Ausrichtung von Blastwave, die schon länger schwelen. Dennis Clarke, seines Zeichens Eigentümer der Marke Blastwave, Admin und derjenige, der die Hardware-Infrastruktur des Projekts stellt, wollte vor allem Pakete für Solaris Express und OpenSolaris bereitstellen und hielt die Zeit für reif, die Solaris-8-Unterstützung zu beenden. Viele Maintainer jedoch, darunter auch pkg-get-Vater Philip Brown, hatten vor allem das Ziel, die auch von Sun offiziell unterstützten und stabilen Solaris-Versionen 8-10 mit Paketen zu versorgen. Das erste Mal eskalierte der Streit im Mai dieses Jahres, als Dennis Clarke den Account von Phil Brown für zwei Wochen sperrte. In dieser Zeit erschienen keine neuen Pakete, da nur Brown über den Schlüssel zum Signieren verfügte.
Fest dürfte nun stehen, daß das Repository einen anderen Namen bekommen wird; ich kann mir nicht vorstellen, wie man so weiter zusammenarbeiten will. Fraglich, ob Sun sich mit den aktiven Maintainern einigen kann und es einen rechtlich, technisch und administrativ abgesicherten neuen Repository-Master kurzfristig geben wird. Ein zentrales, zuverlässiges und integeres Repository für Sun Solaris-Packages sehe ich jedenfalls als conditio sine qua non für das Überleben von Solaris als Basis für Web2.0-Dienste an. Da sind Linux-Distributionen als auch die *BSDen viel viel weiter als Sun mit Solaris. (Daß dazu ein Package-Management mit umfassender Dependency-Behandlung gehört, dürfte klar sein, oder?)
Ich weiß nun zu wenig über die Analen von Debian, dort allerdings scheint das Setup von Individuen weitgehend unabhängig zu funktionieren. Bei Red Hat/Fedora gibt es einerseits die vom Distributor betriebenen bzw. unterstützten Repositories als auch private, teilweise leider nicht zueinander kompatible, Repos. Die Manigfaltigkeit der RPM-Dielekte macht es zudem unntötig schwer, ein Sourcecode-Package (.src.rpm) einer anderen Distribution für Red Hat/Fedora zu übernehmen, die unterschiedlichen Packagenamen tun ihr übriges — der Wunsch, »welcome to dependency hell« nicht mehr zu erleiden, war für mich z. B. ein Auslöser, meine privaten Server von Fedora/CentOS auf Debian (und die Nicht-Server von Fedora auf Ubuntu) zu migrieren.
Ich bin gespannt, wie das Thema »Blastwave« nun weitergeht. Ich werde das wohl am Beispiel von Nexenta, das ja auch betroffen ist, weiter verfolgen.
