 Ok, herzlichen willkommen hier zum Talk von RINMA, denn ich herzliche auf der Bühnebegrüße, der uns eine kleine Einführung geben wird in das Bauen von OurPaketen. Wünsche ich viel Spaß, der Talk ist eine halbe Stunde. Wir wollen 10 Minuten Q&A vielleicht am Ende machen, auch mit der Möglichkeit, diese über das Web zu stellen, über den Stream, aber da wird das gleich noch was zu sagen. Dann viel Spaß! So, erstmal eine generelle Frage, wer von euch nutzt den Acklinux? Wer von euch hat schon mal aus dem A-Uhr ein Paket installiert? Cool. Wer von euch fragt sich, wie die da hinkommen? Nein, das bin ich. Auf jeden Fall, wer will, da kann man Fragen einreichen und voten, ganz oben. Die zeige ich noch mal am Ende die URL und werden das vortratzen. Ok, also worum geht es? Es geht zum ersten um das Ack-User-Repositorium. Dort landen all die Pakete, die keine offizielle Unterstützung haben oder noch nicht in den offiziellen Repos sind, weil viele von den offiziellen Paketen haben halt einmal dort angefangen. Wie kommen die Pakete dahin? Als erstes braucht man ein Account auf der Ack-User-Repositori-Webseite. Wenn man diesen Account hat, lädt man seinen SSH-Key hoch. Denn in diesem Repositori funktioniert alles über Git mit der Identifizierung über SSH. Danach klont man ein Git-Repo. Das ist meistens ein URL, die leer ist. Also man klont dieses Repo und im Normalfall ist es leer. Wenn es nicht leer ist, heißt das irgendjemand hat dieses Paket schon mal gestellt. In dieses leere Repositori erzeugt man dann seine Package-Bild-Pfeil. Was das genau ist, darauf gehe ich heute ein. Man führt noch ein paar Kommandos aus, die wichtige Informationen erzeugen, die das AUS selber braucht. Und dann tut man das Ganze hoch pushen und wenige Sekunden später ist das eigene Paket auch schon verfügbar. Okay, wie sieht so eine Package-Bild nun aus? So, da stehen einige Informationen drin. Und was diese Informationen sind, da gehe ich jetzt so einigermaßen für mich gruppiert thematisch drauf ein. Zum einen geht es am Anfang los mit ein paar Informationen. Wie heißt mein Paket? Welche Version ist gerade verfügbar? Welches Release ist es? Des weiteren Beschreibungen kurz, was ist dieses Paket, was kann es, was macht es? Auch die Architektur wird mitgegeben, damit halt auch weiß, für wen ist dieses Paket bestimmt. Die URL des Projektes, also eine Github-Seite oder die Website des Projekts, und halt die Lizenz. Nicht die Lizenz, unter der man das Paket veröffentlichen möchte, sondern die Lizenz, unter der die Software veröffentlicht wurde. Bei der Architektur kann man so einiges mitgeben. Da gibt es einiges an Möglichkeiten, was unterstützt wird. So, dann ist die Frage, was macht unser Paket eigentlich? Da können wir jetzt sagen, welche Software wird provided? Also, wenn du das Paket installiert hast, was hast du am Ende denn installiert? Mit welchen Paketen steht man im Konflikt? Sagt man, man installiert jetzt eine Software, die installiert eine selbstkombilierte Library. Und diese Library gibt es aber auch als Installation. Dann kann man sagen, wenn du die installiert hast, das gibt Konflikte, entweder kannst du mein Paket nicht verwenden oder du musst halt die andere Library deinstallieren. Welche Abhängigkeiten haben wir? Was braucht die Software, um zu laufen? Welche Pakete müssen noch mitinstalliert werden? Optionale Dependencies sind, wie es halt schon heißt, optional. Die werden am Ende der Installation, wer das schon gemacht hat, weiß, da kommt dann am Ende noch eine kleine Information. Diese Pakete werden sinnvoll, kann man installieren, muss man aber nicht. Des Weiteren gibt es noch die Make Depends und die Check Depends. Die sind jetzt hier grau, weil die sind nicht in meinem Beispiel vorhanden. Die existieren aber auch und Make Depends sind, was brauche ich, um die Software zu bauen und Check Depends, was brauche ich, um die Software zu testen. Nehmen wir jetzt Make Befehle, Make Depends ist halt das Make und Check Depends werden dann zum Beispiel so was wie, wenn es ein Make Test gibt. Jetzt kommt eigentlich das Wichtigste, bisher war eigentlich rein informativ, damit man halt weiß, was installiert wird und jetzt kommt tatsächlich, was installieren wir. In den Source Files kann man zum einen Architektur unabhängige Files angeben, zum anderen aber auch Architektur abhängige Files. Diese können lokal liegen oder halt übers Internet nachgeholt werden über zum Beispiel über GIT oder als ZIP-File, als URL. Die MD5-Sams sagen jetzt die MD5-Summen dieser Sourcen. Das ist ein Security-Feature, wenn die halt nicht übereinstimmen, kann es sein, dass irgendjemand an eurem Paket rumgehandwerkt hat, ohne dass ihr es wisst. Und dann schlägt halt auch die Installation fehl. Da gibt es dann halt auch die Fehlerwarnung MD5-Summen stimmlich überein. Kann natürlich auch passieren, wenn man vergisst diese zu updaten. Die gibt es dann auch Architektur unabhängig und Architektur abhängig. Und was kann man jetzt eigentlich so als Source verwenden? Zum einen kann man verwenden GIT. Man gibt ein GIT-Repro an und das Schöne ist, das Make-Package, das Tooling, das verwendet wird, um diese Pakete zu bauen, weiß sofort, das ist ein GIT, das muss ich auschecken. Ich kann auch ein ZIP-File angeben. Das ist ein ZIP, das liegt unter dieser URL. Muss ich runterladen, muss ich entpacken. Das gleiche mit Tafels. Und mit Debianfalls. Ihr kann auch ein Debian-Paket angeben und er lädt es runter, er entpackt. Worauf man dabei aber achten muss ist, wer ein Debian-Paket schon mal angeguckt hat, weiß, das Debian-Paket ist selber ein Archiv mit nochmal zwei weiteren Archiven drunter. Ich glaube, es war ein Control-Tar und Data-Tar. Die muss man man entpacken, wenn man das möchte. Das alles, wie gesagt, wird automatisch entpackt. Falls man das nicht möchte, kann man auch sagen, du, laht es nur runter, aber entpackst nicht. Entweder brauche ich das gepackt oder ich kümmere mich selber drum. Was machen wir jetzt mit diesen Sourcen? Es gibt ja jetzt verschiedene Dinge, die wir tun können. Es gibt vorgefertigte Funktionen, die werden beim Bau- und Installationsprozess automatisch aufgerufen, darunter Prepare, Build, Check & Package. Prepare wird verwendet, um die Sourcen zu bauen, das Ganze zu kompilieren oder zu entpacken. In Build bauen wir die Sourcen. Also alles, was irgendwie im Bauprozess ist, prepare wird entpackt, build wird kompiliert. In Check führen wir dann unsere Tests aus, ist das, was wir da gebaut haben, überhaupt richtig funktioniert das, kann das, was es soll. Package in dem Block wird die ganze Software installiert. Da schreiben wir alles rein, was getan werden muss, um die Software in den richtigen Zustand zu bringen und auf dem System zu installieren. In all diesen Blöcken kann man ganz gewöhnliche handelsübliche Schellbefehle verwenden, Shell Tools, falls man halt welche braucht, die nicht standardmäßig installiert sind, gehören die halt ins Make Depend oder ins Depend, je nachdem. Und diese werden dann halt nach dem Installationsprozess als brauchen wir jetzt nicht mehr gezeichnet. Anhand meines Beispiels zeige ich euch jetzt mal kurz, wie denn der Package Block zum Beispiel aussehen kann. Was ich hier mache, ich erstelle erst benötigte Ordner. Wem es vielleicht auffällt, da steht Package Tier, das ist eine im Bildprozess zur Verfügung gestellte Variable und in dem Prozess wird ein Source-Folder angelegt und ein Package-Folder. Und das Package Tier zeigt auf den Package-Folder. Wer jetzt genau hinguckt, sieht, das sind irgendwie die Fade drin vom System. Ja, in dem Package Tier wird das Filesystem, also den gewünschten Zustand des Filesystems nachgebaut und beim Installationsprozess werden die Dateien dann halt an den richtigen Ort geschoben, also in dem Fall dann nach Opt oder User Bin. Ich kopiere die Daten dann in meine neu erstellten Ordner, setze noch die richtigen Berechtigungen und füge noch einen Simlink hinzu zu User Bin. Des Weiteren haben wir noch eine Variable Source Tier, das ist wie gesagt der Source-Folder. Ich zeige gleich nochmal, wie das dann aussieht im Filesystem selber. Und wenn dieses Package nun gelaufen ist, dann müssen wir noch ein bisschen was tun. Uns werden ein paar Kommando-Zahlen-Tools zur Hand gelegt, die uns einiges an Arbeit wegnehmen, zum einem Update Package-Sums. Das erzeugt automatisch die MD5-Summen für die Sourcen. Wenn sie noch nicht vorhanden sind, werden sie halt heruntergeladen. Und das fügt auch automatisch diese MD5-Blöcke in das File 1. Das bedeutet, die muss man am Anfang gar nicht reinschreiben. Die kommen da über dieses Tooling rein. Make Package Print Source Info ist jetzt ein Tooling, das wird benötigt für AU. Es legt ein sogenanntes Source-Info-File an. Und dieses Brauch des Repositories, um Metadaten über das eigene Paket zu bekommen. Das Schöne ist, wenn man diesen Befehl vergisst und ein Git push macht, bekommt man vom Git die Rückmeldung, ja, deine Änderungen sind da, weil dein Paket wird nicht live gehen, deine Source Info ist nicht vorhanden oder nicht up-to-date. Das bedeutet, man hat dieses Kommando vergessen und sollte das noch ausführen. Nemcap ist ein Tooling, das macht das beruftes Paket. Und sagt einem zum Beispiel, was da irgendwie Konfig-Files, die hast du in der User-Bin gelegt, nicht so cool, überdenkt das mal nochmal. Natürlich sollte man, bevor man das Ganze ins Rebo pusht, auch mal lokal ausgeführt haben und gucken, das überhaupt tut, was es will, soll, MakePackage macht das Ganze einmal lokal, ohne Installation. Müsste man sich bei sich selber installieren, hängt man halt noch das Minusifleck dran. Und am Ende natürlich nicht vergessen, pushen, sonst kommt das Paket halt nirgends wo an. Wie sieht nun das fertige Produkt aus? Wir haben eine Ordnerstruktur. Die Grünen, das sind lokale Sourcen, die wir selber anlegen, die bereits vorhanden sind. Das Blaue ist alles, was von MakePackage generiert wird. Das Zip-File wurde wie in den Sourcen beschrieben heruntergeladen und dann nach Source unpacked. Und beim Package-Baubrozess haben wir halt in dem Package-Ordner diese besagte Struktur. Und am Ende, das Orangene, kommt halt das Paket raus. Und in diesem Paket liegen alle Daten in der Ordnerstruktur, wie sie in dem Package-Folder liegen. Und das war ein bisschen schneller als gedacht. Das Ganze ist, wie gesagt, nicht sehr schwer, ziemlich einfach. Er hat mir das am Anfang auch alles sehr mystisch, sehr ... Das, was die da machen, das ist schon wieder eine Linux Magic und unglaublich viel Wissen. Aber es ist tatsächlich nicht mehr als das Pfeil mit den paar Informationen. Und das Schwierigste ist tatsächlich, die richtigen Kommando-Zeilen in die richtige Funktion zu packen. Das ist die komplette Magic in der Arc-User-Repository-Pakete selber bauen. Wenn es jetzt Fragen gibt, Handmikro hier. Du hast ja gezeigt, dass du auch die Source-Dateien, da direkt, wenn man die aus dem Internet holt, angemkannst, dass die für eine bestimmte Architektur sind? Nein. Ja. Es ist jetzt so, du musst selber die richtige Architektur raussuchen und halt gucken, ob sie die Software unterstützt und dann halt in den passenden Source-Block packen. Die Source-Blocke können auch die gleichen Architektur-Bezeichnungen haben, wie im Infoblock dieser Architecture. D.h., du machst halt ein Source-Unterstrich x8664 oder source-AM7 und packst halt die passenden Sourcen rein. Aber wenn ich jetzt zum Beispiel mein Paket für verschiedene Architekturen anbieten will, kann ich dann für jede Architektur einen eigenen Source-Block machen? Ja, du kannst zu viele Source-Blocken machen, wie du Architekturen unterstützt. Dass der richtige Source-Block für die richtige Architektur verwendet wird, da kümmert sich am Ende der Installationsprozess drum. Der weiß ja, welche Architekturen du unterstützt und weiß dann auch, welche Sourcen du ja verwenden musst. Lässt sich auch was anderes als MD5 verwenden? Nein. Schade. Nicht, dass ich müsste, weil das Update-Package-Sum generiert halt MD5. Hier gibt es eine Frage. Wie stellt man sich da, dass alle Bild-Dipendencies gelistet sind? Gibt es sowas wie Reproducible-Bilds? Nein, dass alle Bild-Dipendencies gelistet sind, darum muss man sich selber kümmern. Da gibt es jetzt kein großes Tooling, das das macht. Ich verstehe nicht ganz, was mit Reproducible-Bilds gemeint ist. Ja, die Pakete sind reproduzierbar. Ansonsten gibt es noch Kammergrosskompilen? Nein. Immer nur das Paket auf der eigenen Architektur kann man bauen. Man kann nicht auf der einen Architektur für eine andere bauen. Wie sind es mit mehreren Paketen, die aus anderen selben Quellen entstammen? Gibt es Möglichkeiten, beispielsweise verschiedene Flavors aus anderen selben Quellen aus einem der selben Package-Bild zu generieren? Da muss ich, wenn ich, habe ich die Möglichkeit mit einem Package-Bild mehrere Pakete zu generieren? Nein. Was ich zum Beispiel mache, er hat ein Paket gebaut für die Game Engine Godot, für die Mono-Version. Er hat dann ein Paket, das macht von Git, baut von den Sourcen. Das gebe ich einmal eine Version mit, wo er auschecken soll. Wenn ich jetzt aber möchte, dass er vom Master baut, muss ich nochmal eine extra Package-Bild bauen, wo ich dann sage, nicht von der Version auschecken, sondern vom Master. Ich kann jetzt nicht sagen, irgendwie einen Fleck mitgeben, wo er dann sagt, entweder das oder das. Okay, danke. Ich bekomme gerade in den Kommentaren gesagt, es gehen auch andere Checksummen. Gut, wusste ich nicht, wie da was gelernt. Weiß halt leider nur nicht, wie. Und da hinten wäre eine Frage. Und zwar kann man ja, wenn man aus den normalen Repositories was installiert und man hat die optionalen Dependencies, dann wird ja dahinter noch angegeben, aus welchem Grund ich die optionalen Dependencies eventuell installieren möchte, Provides XY. Habe ich die Möglichkeit, bei Aua auch da einen Grund für einzugeben für meine optionalen Dependencies? Gute Frage, habe ich noch nie nachgeguckt. Aber wenn es das, vielleicht weiß es einer in den Kommentaren. Ich weiß es nicht. Hier kommt jetzt auch gerade nichts mehr rein. Wenn es sonst keine Fragen mehr gibt, dann würde ich sagen, herzlichen Dank. Und nach einer kurzen Pause haben wir dann als nächstes Audio Processing, hier im Raum.