Common Installation API

Mir ist die Tage eine Idee gekommen, wie man eventuell die Problematik rund um die Installation von Software auf verschiedenen Linux-Distributionen lösen könnte.
(Mir ist übrigens klar, dass ich nicht der erste bin, dem solche Ideen gekommen sind – nur finde ich, dass die meisten die Problematik des zweiten Beispiels [s.u.] gar nicht ansprechen…)

Das allgemeine Problem ist bekannt: da es eine Vielzahl von Linux-Distributionen gibt, muss ein Päckchen Software, sagen wir mal ein Bildbearbeitungsprogramm, theoretisch für jede Distribution einzeln verpackt werden – im Worst Case für jede Version jeder Distribution, was Linux vor allen Dingen für kleinere Softwareanbieter unattraktiv macht.

In der Praxis ist es nicht gerade nötig, zig Pakete zu erstellen, in Einzelfällen kann es aber schon mal vorkommen.

Eine Möglichkeit, dem zu entgehen ist unter anderem, die Linux-Distributionen zu vereinheitlichen, was durch die Linux Standard Base gemacht wird.
Doch dann bleibt noch immer das Problem, dass fast jede Distribution mit ihrer eigenen Paketverwaltung daher kommt. Was da tun?

Hier setzt nun meine Idee an, eine Art Installations-API zu bauen. Diese würde jedem Nutzer und jedem übergebenen Paket eine einheitliche Struktur anbieten, und würde so die Installation von Paketen erheblich vereinfachen.

Um deutlicher zu werden, einige Beispiele:

Beispiel a): ein Nutzer will Software xyz installieren.

Statt wie früher findet er auf der Homepage der Software unter dem Begriff Download nur noch ein Paket für Linux. Er klickt es an, und der Browser startet das zugehörige coin-Gui (“Common-Installation”😉 ). Dieses öffnet das Paket, erfährt davon die Abhängigkeiten, und leitet diese zur Auflösung an die API weiter.
Diese wandelt die Abhängigkeiten nun in die distributionseigene Sprache um – sei es, dass es ein apt-get Aufruf wird, sei es, dass yast seine Finger im Spiel hat, urpmi oder auch yum, Ports oder Portage – die wichtigen Aufgaben können dabei von allen Werkzeugen erledigt werden.
Wichtig ist dabei aber, dass das coin-Paket keine expliziten Paketnamen enthält, sondern auf Bibliotheken und Programme und die entsprechenden Versionen verweist und diese fordert.
Ist es dem distributionseigenen Programm nicht möglich, die Abhängigkeit aufzulösen, weil z.B. die Distribution zu alt ist (oder nicht genug Quellen zu Verfügung stehen), gibt es eine Fehlermeldung, werden alle Abhängigkeiten aufgelöst, lädt die Distribution diese mit Bordmitteln und gibt ein OK an die coin-gui. Das Programm ist installiert. Möglich wäre an dieser Stelle noch, wenn sich nicht jedes coin-Paket als rpm-Paket plus einige weitere Infos verpacken ließe, dass von coin eine Art Metapaket an die Distributionswerkzeuge übergeben wird, um dort weiterhin Konsistenz zu gewährleisten.

Beispiel b): ein Nutzer will ein Softwarerepository xyz installieren.

Da Software ständig aktualisiert wird, macht es Sinn, die eigenen Softwarequellen mit neu installierter Software auch um weitere Quellen zu erweitern.
Dies kann auch geschehen, wenn man z.B. Software kauft, und diese regelmäßig aktualisiert wissen will, aber keine Lust hat, immer selbst danach zu gucken.
Um dies zu gewährleisten, sollte es coin-Repositories geben, die direkt mit in das Paket reingeschrieben werden, damit bei der Installation des coin-Pakets gleich auch die Quelle für Updates mit übernommen wird. Wird dieser Mechanismus auch mit einer Passwort-Abfrage-Fähigkeit, Verschlüsselung und verschiedenen Authentifizierungen erweitert, wären so auch Anforderungen erfüllt, welche proprietäre Hersteller an Softwaredistribution haben.

In der Anfangszeit würde coin somit vor allen Dingen ein Bindeglied zwischen den Distributions-Werkzeugen und einer einheitlichen Softwarewelt werden, später könnte man coin auch so aufbohren, dass es die Quellen der jeweiligen Distributionswerkzeuge einliest und übernimmt, und sich selbst vollständig um den Download und die Aktualisierung der Pakete kümmert.

Schließlich würde es dann darin münden, dass die meisten großen Linuxanbieter alle das gleiche Software-Verwaltungswerkzeug nutzen würden – bis es so weit ist, wird es aber noch ein langer Weg sein, weswegen die Zwischenstufen nötig sind.

Das aber wenigstens die Masse eine einheitliche Softwareinstallation benötigt, sollte allen Beteiligten klar sein.

2 thoughts on “Common Installation API”

  1. Interessanter Gedanke auf jeden Fall. Hast du die Inspiration irgendwo aufgeschnappt?

    Ich bin zurzeit leider ziemlich ausgelastet und habe noch andere Projekte, die auf den richtigen Startschuss warten, sonst würde ich das Thema gerne weiter vertiefen wollen.

    Sollten sich noch andere Leute hierfür interessieren, ließe sich ja ggfs. eine Art Diskussionsforum/Mailingliste aufbauen. Dort könnte man vor der Realisierung erst einmal grundlegende Konzepte (Paketformat u.Ä.) diskutieren. Da wäre ich dann auch dabei.

  2. Nein, die Idee kommt von mir – sie ist aber in etwa in Autopackage umgesetzt, nur fehlen auch da jede Menge Aspekte (eigene Repositories, Repos mit den Paketformaten installieren können, etc.).

    liquidat

Comments are closed.