Das Pisi Linux Paket Management   Leave a comment

Pisi Linux Paket Management

Der offensichtlichste Aspekt von PiSi ist seine Einfachheit. Von seiner svn-ähnlichen Konsolenschnittstelle – pisi-cli, bis zu seinem Paket Bau Mechanismus ist es sehr einfach, das Innenleben zu erfassen und effektiv zu nutzen. Es ist so einfach, dass, als der erste PiSi Quellcode mit einigen Beispiel-Source-Pakete offenbart, es nur zwanzig Minuten für jemanden dauerte, ein neues Paket zu Pardus beitragen. Und es gab keine Dokumentation über das Build-System. XML-basiertes Quell Verpackungssystem ist so intuitiv und einfach zu begreifen, dass es fast keine Dokumentation braucht.

 

Wenn Sie zu einem traditionellen Paketmanager schauen, können Sie sehen, dass die Vielzahl von Werkzeugen für die Verwaltung um das Paket Gebäude, zu erstellen ist es ein unnötig kompliziertes System.

 

Die erste Komplikationen kommen von den verschiedenen Tools, die, kombiniert werden, das gewünschte Paket-Management möglich zu machen. Die so genannten nativen Paketmanager (DPKG, RPM, etc.), die die Housekeeping-Jobs tun und über ihnen gibt es viele andere ‚Wrapper‘ Tools (apt, dselect, urpmi, yum, aptrpm, etc.) vor allem für den Umgang mit der Abhängigkeits Auflösung, Paket-Auswahl und dem Installation Problemen. Aber die Hauptkomplikation und Schwierigkeit kommt von den verschiedenen Build-Helfer-Tools, Ad-hoc-Source-Spezifikation Formate und die Build-Skripte. Die Lernkurve ist hoch für neue Entwickler.

 

PiSi Architektur ist ganz anders als traditionelle Designs. Jeder Zusammenhang mit Management-Funktionalität wie die Installation, den Aufbau, die Abhängigkeit zu lösen, Validierung und Repository-Management ist im Kern der PiSi zu verpacken. Auf der anderen Seite wird die Paketkonfiguration deutlich von dem Paket-Management-System getrennt und delegiert durch COMAR. Das Konfigurationssystem ist nicht begrenzt, zu entfernen oder Post-Install-Skripte, es ist ein viel weiter fortgeschrittenes System, Konfiguriert, alle installierten Pakete in einer einzigartigen Art und Weise mit der gleichen COMAR API. Ein Paket kann einen Konfigurationsdienst-Script als Konfigurationsoberfläche selbst verwenden. Konfiguration der Pakete können remote oder lokal ausgeführt werden.

 

Traditionell gebaute Skripte für Pakete sind Shell-Skripte. Die Shell ist ideal für einfache Aufgaben, wie Stapelverarbeitung einer Reihe von Befehlen, mit vielleicht einigen conditionals aber nichts mehr. Shell Scripting ist umständlich. Es braucht noch viele weitere Helfer-Tools mit ihrer eigenen Syntax zur Verwendung. Darüber hinaus gibt es hohe Debugging-und Wartungskosten. Wenn es zu komplexen Aufgaben wie der Bau eines Pakets kommt, bedingte Operationen, String-Manipulationen, Iteration über Datenreihen, und viele andere Operationen brauchen Sie höhere Scripting-Sprachen, zusammen mit zusätzlichen Vorteilen. Und aus diesen Gründen wurde Python für alle Kernkomponenten der Distribution aufgrund seiner Einfachheit, Flexibilität und Lockerung der Wartung gewählt.

Veröffentlicht 15. Oktober 2014 von groni

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: