LURE: das Linux User Repository

News 39 Kommentare

Für viele Arch-User ist das Arch User Repository (AUR) ein entscheidender Grund, Arch zu nutzen. Das seit 2005 gepflegte Online-Repository für Anweisungen zum Erstellen von Paketen für diverse Pacman-Wrapper bietet derzeit über sogenannte PKGBUILDs den Bau von rund 80.000 Paketen an.

Grandios gescheitert

Im Sommer 2021 wurde das Projekt Debian User Repository (DUR) angekündigt, dass das AUR auf Debian übertragen wollte, mittlerweile zu makedeb umbenannt wurde und sich wegen viel Kritik seitens Debian derzeit mehr in Richtung Ubuntu LTS orientiert. Anfangs beschwerten sich Anwender, dass das Tool ihre Installationen geschrottet hätte.

Noch handwarm

Ganz frisch auf Gitea stellt der Entwickler Arsen Musayelyan ein Projekt vor, das die Idee des AUR auf mehrere Distributionen übertragen möchte. Das in Go geschriebene Projekt ist derzeit in einer frühen Alpha-Version verfügbar und deshalb mit Vorsicht zu genießen. Derzeit werden apt, pacman, apk (Alpine, nicht Android), dnf, yum, und zypper unterstützt.

An PKGBUILD angelehnt

Das Prinzip klingt simpel: LURE lädt ein Repository herunter, baut mit einem Bash-Skript ähnlich PKGBUILD Pakete darin, die dann mit dem Paketmanager der installierten Distribution installiert werden. Derzeit gibt es noch keine Binärpakete, LURE muss aus den Quellen erstellt werden. Voraussetzung ist Go 1.18 oder neuer. Nach Download oder Klonen des Repositories genügt ein go build innerhalb des Verzeichnisses. Danach kann das Ergebnis mit sudo install -Dm755 lure /usr/local/bin installiert werden.

Mehrere Repositories unterstützt

Anders als das AUR unterstützt LURE die Verwendung mehrerer Repositories. Ebenfalls im Gegensatz zu AUR sind die LURE-Repositories ein einziges Git-Repository, das alle Build-Skripte enthält. Innerhalb jedes LURE-Repositories sollte es ein separates Verzeichnis für jedes Paket geben, das ein lure.sh-Skript enthält, das ein PKGBUILD-ähnliches Build-Skript für LURE ist.

Was haltet ihr von diesem Projekt? Kann das funktionieren? Ich hoffe, ihm ist mehr Erfolg beschieden als dem mit vielen Vorschusslorbeeren versehenen DUR, das nie wirklich abgehoben hat. Ich werde LURE auf jeden Fall im Auge behalten. Auf Reddit gibt es eine Diskussion zum Thema.

Teilt den Beitrag, falls ihr mögt

39 Kommentare

    1. Wo siehst du denn Verknüpfungspunkte mit Flatpak? Flatpak ist darauf ausgelegt, alle Abhängigkeiten zu bündeln, während LURE für native Paketierungsformate baut, die darauf ausgelegt sind, ihre Abhängigkeiten aus Repos zu beziehen.

      1

      1. Ich sehe es da drin, das ich keine bzw. viel zu wenig Einfluss nehmen kann.
        Ehrlich gesagt bin ich eher der, der genau kontrollieren will, was gemacht wird.
        Deswegen favorisiere ich immer noch den Paketselbstbau, wenns denn sein muss.

        Das gehoert fuer mich einfach beim Linux dazu, genau wie sich einen individuellen Kernel backen.

        0

          1. Ich bin gegen jedwede Geschichte, die die Distributionen einschleicht um eine Art Einheitsbrei draus zu machen, ganz egal wie sie heissen.
            Natuerlich hast Du Recht, das LURE eine viel Bessere Geschichte wie snap oder Flatpak sind, da sie auch in meinen Augen ein viel besseres Konzept (Hinsichtlich Distro-Integritaet) bieten aber dennoch lehne ich das ab.
            Auch erkenne ich darin keinen wirklichen Mehrwert.
            Man kann alles auf sein system installieren was man will, dazu braucht es auch kein LURE

            0

            1. > Man kann alles auf sein system installieren was man will, dazu braucht es auch kein LURE

              In der Tat, allerdings muß man in dem Falle auch jeden Tag/ regelmäßig manuell schauen ob es ein neues Release gibt. Oder für jedes Progrämmchen einmal ein Updatescript schreiben, welches die Schritte wegautomatisiert.

              0

              1. Du willst jeden tag schauen ob’s ein aktuelles Paket gibt?
                Ach Du Scheisse. Dann solltest Du auf testing gehen.

                Also ich will stabile Instanzen. 😉
                Was ist denn so wichtig, das man staendig die neusten Pakete haben muss?

                0

                    2. Ja sicher, wobei man auswaehlen sollte.
                      Das ist eben wenn die Updates die Distro veroeffentlicht, dann ist man auch vor Seiteneffekten sicherer.
                      Nuetzt ja nix, wenn ein update eines “Fremden” paketes, wo anders wieder Loecher reist.

                      0

    1. Anstatt Debian mit so was zu verunreinigen, fände ich es besser, Bug Reports bei Debian zu schreiben, ODER in nixos zu paketieren.

      Werden das die Befürworter jemals verstehen, ich habe daran starke Zweifel. Deswegen hat sich die Mehrheit der Debian Maintainer auch dagegen ausgesprochen.

      So wird man bloss über kurz oder lang das System kaputt machen.

      Soweit möchte ich nicht gehen, aber der Supportaufwand der vielen Freiwilligen wird massiv zunehmen. Aber es gab auch einige Meldungen zu unrettbar zerstörten Systemen.

      0

      1. Ja, ich glaube auch, dass der Supportaufwand zunehmen wird.

        Es ist einfach keine gute Idee paketdatenbanken und FQDNs von Inhalten zu vermischen. Daher mag ich persönlich den Ansatz für Stabilität eine kleine Debian Base (auch mit desktop und LO, aber halt kleiner gehalten), und sonst NixOS (oder auch Container, Flatpaks, Appimage) für neueres.

        Ich könnte mir gut vorstellen, dass es das für Debian in Zukunft auch einfacher macht, wenn nicht mehr jeder, entschuldigung, Mist in Debian ist, sondern halt lieber als stationäres Paket (auch uralte Pakete können da ja weiterbetrieben werden..) in NixOS und Debian Repositories eine rundere, kleiner und damit besser wartbare Basis sind.

        0

  3. Finde die Idee auch gut. Es ist nunmal nicht immer einfach ein Paket in eine Distro zu bekommen und daher braucht es oft einen Mittelweg. Ziel sollte natürlich trotzdem sein, dass ein Paket direkt in der Distro maintained wird.

    0

  4. Ich finde die Idee jedenfalls Spitze. Das AUR war damals für mich tatsächlich einer der Hauptgründe gewesen zu Arch zu wechseln. Es besteht kein Grund weshalb man das Prinzip nicht auf andere Distributinen ausweiten sollte. Für Entwickler wird es dadurch auf jeden Fall sehr viel einfacher ihre Software schon einmal bekannt zu machen.

    Der distributionsübergreifende Ansatz ist denn auch ein wichtiger Unterschied zum Dur Projekt und gute Funktionalität vorausgesetzt besteht hierdurch sogar ein Potenzial das AUR langfristig zu ersetzen.

    1

  5. Ich stelle es mir schwer vor, fuer alle Distros die Abhaenigkeiten sauber halten zu koennen. Passiert im AUR ja schon oft genug, dass die Pakete hin und wieder angepasst werden muessen – bei mehreren Zieldistros kann das doch eigentlich nur ein riesiges Chaos werden?

    0

  6. Flatpak/Snaps gibt es ja aus dem Grund, weil man so ein Gebilde wie das AUR technisch nicht haben will und eigentlich so wenig wie möglich bis gar nicht benutzen sollte.

    “Eigentlich” muss man den Quellcode, bzw. das Buildskript genau prüfen, bevor man es ausführt unter Arch und das ist für niemanden praktikabel, es sei denn man hat absolut keine Wahl.

    1

    1. Warum soll das nicht praktikabel sein? Wenn man die sources kontrolliert und im eigentlichen Build-Bereich keine allzu komischen Sachen passieren hat man schonmal 95% der Angriffsflaeche geschlossen. Dazu bieten sowohl das AUR auf der Webseite, als auch manche AUR-Helper die Moeglichkeit, ein diff des PKGBUILD anzuzeigen wenn man updaten will, das macht die Sache nochmal einfacher.

      Aber klar, fuer jemand voellig unbedarften ist das auf jeden Fall eher mit Vorsicht zu geniessen!

      1

      1. Nicht praktikabel heißt, dass Mehrarbeit ohne Mehrnutzen generiert wird. Für alle User ist es weniger Arbeit, wenn an zentraler Stelle die Sources und die Buildscripts geprüft werden, damit das niemand anders mehr machen muss. Was die AUR für Arbeitszeit bindet auf alle User bezogen…

        Außerdem verstehe ich Computer als Erleichterung von Arbeit, und jede Woche eine Stunde bei AUR Updates Skripte zu prüfen empfinde ich als Arbeitschaffungsmaßnahme. Die Wartung bei einem fertig konfigurierten PC sollte gegen 0 gehen.

        0

        1. Das ist aber eben nicht die Wahl, die du hast – die lautet: entweder die entsprechende Software gar nicht nutzen oder manuell aus den sources bauen oder eben das AUR-Script kontrollieren.
          Und ‘jede Woche eine Stunde’ ist masslos uebertrieben. Ich habe schon einige AUR-Pakete installiert und die Kontrolle frisst in schlimmen Wochen vielleicht 10min, das ist dann aber schon ein extremer Ausreisser nach oben – in den meisten Faellen hat sich eh nur die Version und/oder die source geaendert, dann ist die Kontrolle bei Updates nach 5sec erledigt.

          Klar waere es idealer, wenn JEDE Software, die es irgendwo auf dem Planeten gibt von vertrauenswuerdigen Distro-Maintainern gepackaged wuerde, aber DAS ist eben tatsaechlich nicht praktikabel…

          0

    2. Ganz fundamental widerspricht so ein AUR allen Sicherheits- und Stabilitätsgrundsätzen von Debian. Das kann nur einfach “nicht supported” sein aus Sicht von Debian.

      Aus Sicht von Debian soll man das Paket ja auch ordentlich maintainen und upstream in Sid einpflegen, so dass es nach unten zu Stable runtertropft. Debian rät ja generell von fremdrepositories ab, und empfiehlt höchstens die Backports.

      1

      1. Man muss hier klar unterscheiden, zwischen dem Anspruch der Maintainer für Stabilität und Sicherheit Sorge zu tragen und dem Recht des Users mit seinem System frei umzugehen und Risiken auch mal selbst zu tragen.
        Wenn Debian sagt, dass wird nicht offiziell von Debian empfohlen, dann ist das völlig o.K aber auch kein Hinderungsgrund so ein Projekt nicht allein zu stemmen.

        0

        1. Das Recht hat der Benutzer natürlich. Das Problem ist aber halt, dass der Benutzer gar nicht überblickt, welche der Pakete sein System kurz oder langfristig kaputt macht.

          Daher wäre es halt gut, wenn etwas wie NixOS verwendet wird, oder wenigstens schaut, ob derzeitige oder zukünftige Paket-inhalte (Dateien und Pfade) von so einem LURE Pakete konfliktieren.

          weil danach ist in den hilfe channeln von debian oder ubuntu das geschrei wieder gross.

          0

          1. Das habe ich bei Manjaro auch mokiert. Da wird flott eine GUI zu einem AUR Helper gestrickt und Leute die kein einziges Script lesen können klicken dann munter die AUR PKGBUILDs an.
            Das ist nicht mein Geschmack, aber es scheint trotz der Gefahren fast immer gut zu gehen.

            0

            1. Vermutlich weil die systeme oder einzelne pakete nicht lang genug leben um schaden anzurichten, den man merkt.

              ich kenne diverse leute, die jahrelang vorsichtig mit frankendebians gelebt haben (mint, ubuntu und debian gemixt als repo………) aber irgendwann kracht es halt. die frage ist: was will man.

              und ich will nicht dass meine paketdatenbank mir kaputt geht noch dass es paketkonflikte gibt, die nicht gelöst werden können.

              0

              1. Bei Arch ist das so nicht der Fall.
                Arch ist, soweit ich es blicke aus der Idee entstanden mit kleinen Scripten das System selbst zu bauen. Später hat man dann die selben Anleitungen (PKGBuilds) genommen um die beliebtesten Pakete in Repositories auch binär vorzuhalten. Es ist ein Vorurteil, dass PKGBuilds automatisch zur Intstabilität führen.

                0

                  1. Interessanter Link. Werde ich mal näher studieren.
                    Was meine Überzeugung angeht, dass Arch wohl so angefangen haben muss, geht aus Wiki-Artiken wie diesem hervor.
                    Die Repos wie core, community und extras sind ja nur Abstufungen im Vertrauen und in der Gründlichkeit mit der die Binaries getestet werden. Das Buid-System unterscheidet sich aber nicht vom AUR.

                    Oder mal hier für LURE argumentiert: Wenn LURE die PKGBuilds mit eigenen Maintainern vorab kontrolliert und testet, dann sind auch die möglichen Gefahren minimiert.

                    0

      2. Ganz fundamental widerspricht so ein AUR allen Sicherheits- und Stabilitätsgrundsätzen von Debian.

        So sahen das die meisten Debian Maintainer auch und haben dankend abgewunken. Die Karawane ist nun weiter gezogen.

        0

Kommentar hinterlassen