AUR für Debian?

[Blue]

AUR soll für Debian möglich werden: https://gnulinux.ch/aur-fuer-debian . Mit dem entsprechenden Namen "DUR".
AUR ist imho verführerisch einfach, aber tatsächlich ein Trouble-Shooter, weil es Abhängigkeiten großzügig ignoriert.
Ich habe eine Zeit lang Manjaro mit AUR betrieben und war nach anfänglichem Zuspruch schnell ernüchtert.

Aber was wißt, meint, sagt Ihr dazu?

[schwedenmann]

Hallo

Finde ich für debian weniger sinnvoll

1. Debian hat per se die größere Paketbasis, da braucht es keine AUR oder DUR. Bei Arch sieht das erheblch anders aus,wenn man die AUR nciht mitrechnet.

2. Gibt es genug Fremdpakete als deb,falls mal was nicht in den Repos ist.


mfg
schwedenmann

[DeletedUserReAsG]

AUR ist imho verführerisch einfach, aber tatsächlich ein Trouble-Shooter, weil es Abhängigkeiten großzügig ignoriert.

Die Abhängigkeiten sind in den PKGBUILDs hinterlegt (wenn nicht, schreibt man einen Bugreport, oder behebt es selbst und lädt es hoch – aber ich hab da noch kein Problem feststellen können, und ich hab so einige Pakete aus dem AUR – seit einigen Jahren). Wenn jemand sich nicht darum kümmern möchte, kann er einen der AUR-Helper nehmen, und die kümmern sich drum: Ich, z.B., nutze derzeit yay – auch, wenn’s das ganze Go-Geraffel als Build-Abhängigkeit hat – damit lässt sich das AUR wie die normalen Repos benutzen, incl. Updates und Abhängigkeitsmanagement. Was das angeht, funktioniert AUR hier ganz ausgezeichnet.

Debian hat per se die größere Paketbasis, da braucht es keine AUR oder DUR. Bei Arch sieht das erheblch anders aus,wenn man die AUR nciht mitrechnet.

Und wenn mal ’n Paket etwa aus Lizenzgründen, oder weil sich keiner gefunden hat, der sich drum kümmert, nicht drin, oder das Vorhandene einfach nur zu alt ist, oder man aus $Gründen konkret die Upstream-Version benötigt (etwa für Bugreports), steht man da. Auch was das angeht, könnte ein AUR-Äquivalent durchaus Vorteile bringen.

Und wenn man sein eigenes Projekt für eine Distribution verfügbar machen möchte, gibt es nur wenig Einfachereres und Schlankeres, als eine PKGBUILD im entsprechenden Repo.

Den größten Nachteil würde ich darin sehen, dass jemand, der sowas nutzt, wissen sollte, was er da macht. Debians „walled garden“ ist ein ziemlich guter Garant dafür, dass alles gut zusammen funktioniert. Mit einem User-Repo ist das nicht zwangsläufig gegeben. Im Gegensatz zu Buntus PPAs kann man hier aber immerhin schnell gucken, was tatsächlich im Paket landet – wenngleich das AUR in der Vergangenheit leider auch schon als Angriffsvektor missbraucht worden ist, weil eben kaum jemand tatsächlich geguckt hat. Möchte aber auch nicht wissen, wieviele Systeme über Pakete aus einem PPA kompromittiert worden sind …

Unterm Strich, und nur meine persönliche Meinung: ich finde die Idee ganz ausgezeichnet – nicht zuletzt, weil sie dazu führt, dass man korrekte Debianpakete mit einem einfachen Build-Script bauen können muss (der Paketbau ist ja derzeit doch nicht soo gut zugänglich …). Aber es ist nicht für jeden was, und für etwa einen Einsteiger, der damit mal ’ne Handvoll kommerzieller Sachen installieren und von dem Rest auch gerne das Neuste drauftun möchte, bedeutet es mit einiger Wahrscheinlichkeit ein kaputtes System.

OT:
https://www.dict.cc/?s=Troubleshooter – ist vielleicht nicht, was du ausgedrückt haben wolltest?

[kalle123]

Bei ARCH wohl eine Notwendigkeit aber bei DEBIAN?

Hab irgendwann mal nen ARCH Desktop parallel gefahren und musste für 2 ... 3 Sachen auf AUR zurückgreifen, wo es bei DEBIAN aktuelle *.deb Pakete gab. Und die AUR Sachen waren alles andere als aktuell. Nein Danke!

Aber es ist interessant, nach langer Zeit wieder mal bei AUR zu suchen. Seh gerade, 'timeshift' erfreut sich da anscheinend großer Beliebtheit. Hätte ich nicht gedacht, ist doch nur was für Schwächlinge

cu KH

[DeletedUserReAsG]

Hab irgendwann mal nen ARCH Desktop parallel gefahren und musste für 2 ... 3 Sachen auf AUR zurückgreifen, wo es bei DEBIAN aktuelle *.deb Pakete gab. Und die AUR Sachen waren alles andere als aktuell.

In welcher Realität war das denn? Aktuelle Pakete in Debian (ohne weitere Zusätze ja „Stable“) und veraltete Pakete aus dem AUR (wo ja in der Regel direkt auf den Upstream, teils gar auf Git, zurückgegriffen wird, um das Paket zu erstellen)? Es gibt einige verwaiste Buildscripts (Pakete sind ’s ja nicht, die werden ja erst gebaut) im AUR, aber im Normalfall sind die auch so geflaggt, und in den meisten Fällen reichts, die aktuelle Version und den dazugehörigen Hash in die PKGBUILD zu schreiben.

[kalle123]

In welcher Realität war das denn?

In meiner Realität des Modellbaus, Hier speziell ein open source BS für Fernsteuerungen, Nennt sich openTX.

https://aur.archlinux.org/packages/?O=0 ... _Search=Go

Wie man an den Zahlen sehen kann, ist die Schnittmenge zwischen ARCH und Modellbau, naja, überschaubar.

Aber ist sogar aktuell, was ich da sehe. Nur, die 2.3.12 war 'buggy' und wurde vor kurzem von der 2.3.13 abgelöst. Auch da höre ich von Problemen, als zurück auf 2.3.11 und die findet man da nicht.

Ich fahre die 2.2.4 auf meinen Sendern, nicht das allerneuste, aber stabil und supported und die 2.1.9 ist 'tot'.

https://www.open-tx.org/

Zum Zeitpunkt, wo ich an ARCH dran war, so ~ 2015, sah es da bei AUR sehr traurig aus. War eine interessante Erfahrung, mal ein BS von Null her aufzubauen. Aber das war es denn auch.

Jedem das sein .....

cu KH

[DeletedUserReAsG]

Wie man an den Zahlen sehen kann, ist die Schnittmenge zwischen ARCH und Modellbau, naja, überschaubar.

Hm. So viel an Software gibt’s für den String „opentx“ nunmal nicht. Aber schauen wir doch mal bei Debian, weil du ja meintest, dort würde es diesbezüglich besser aussehen: https://packages.debian.org/search?keyw ... ection=all – ups

Gerade OpenTX Companion hab ich grad vor Kurzem aus dem AUR installiert – keine Probleme, arbeitet ganz ausgezeichnet mit der TX16s mit 2.3.11 zusammen – war aber kurz vor dem Release von .12 – hab das auch gar nicht so verfolgt, weil so Fernbedienungen hängen nicht am Netz (außer Spektrums neue NX, und die iX – wenn’s bei denen denn mal funktioniert ^^), so dass Sicherheitsupdates irrelevant sind, und Featureupdates nur um der Updates willen halte ich auch nicht für sinnvoll – da kann man schon noch nach der alten Devise „Wenn es nicht kaputt ist, reparier’s nicht“ vorgehen, denke ich. Und dass nach .12 direkt .13 kam, deutet eh drauf hin, dass man nun erstmal etwas abwarten sollte, ob sich nicht weitere Fehler zeigen, bevor man’s sich auf die Funke tut. Zumindest, wenn man seine Flieger/Helis mag

Auch da höre ich von Problemen, als zurück auf 2.3.11 und die findet man da nicht.

Wenn du das Paket aber nicht gelöscht hast, was in Zeiten heutiger Speichermöglichkeiten in der Regel auch nicht erforderlich ist, und daher nicht gemacht wird, hast du das alte Paket im Cache, und kannst die neue Version direkt damit downgraden – überhaupt kein Drama. Und wenn du, warum auch immer, das alte Paket gelöscht haben solltest, dann holst du dir die PKGBUILD für opentx-companion-bin, öffnest die im Editor, schreibst da die gewünschte Versionsnummer und den passenden Hash rein, und baust damit das passende Arch-Paket aus dem von den Entwicklern bereitgestellten Debianpaket. Oder falls du aus den Sourcen bauen möchtest, kannst du das Gleiche mit der PKGBUILD von opentx-companion machen – ebenfalls kein Drama.

So allgemein ist’s halt so, dass im AUR gar noch aktuellere Sachen zu haben sind, als selbst in den Arch-Repos. Und die sind, verglichen mit Debian (abgesehen von Sid, meistens) schon „bleeding edge“. Ich bau mir beispielsweise FreeCAD gerne aus dem AUR, obwohl’s im Repo ist – weil ich dort eben ohne großen Aufwand an die neusten Features komme, und mich mit yay auch nicht weiter um Abhängigkeiten und so kümmern muss. Klar hakt es manchmal auch: am WE ließ sich FreeCAD so nicht bauen, weil libboost geupdated wurde, und die Upstream-Sourcen sich nicht ohne Eingriffe gegen die neue Version bauen ließen.


OT: weder Arch, noch Debian, sind Akronyme, und werden daher auch nicht durchgängig großgeschrieben.

[kalle123]

Aber schauen wir doch mal bei Debian, weil du ja meintest, dort würde es diesbezüglich besser aussehen: https://packages.debian.org/search?keyw ... ection=all – ups

Braucht es auch nicht, denn openTX liefert schon lange die *.deb Pakete. Früher gab es mal dazu noch rpm, aber das ist Vergangenheit.

Und wenn ich den *.deb Paketen direkt vom 'Erzeuger' hier oder z.B. auch bei der Arduino IDE nicht mehr trauen soll/kann, dann kann ich auch den Rechenschieber wieder raus kramen und die Korrespondenz auf Briefform umstellen.

(Hab mir gerade eben mal das Durcheinander bei der Arduino IDE in der Aur angeschaut. Nein danke!)

Ich schreib jetzt noch mal. ARCH Arch ist ne tolle Sache, aber ich bin nur User und brauch ein BS, das, einmal eingerichtet, 'stinklangweilig' ist und läuft und läuft und läuft. Und das ist DEBIAN Debian!

cu KH

FrSky X9D und X9D+, eine davon mit MPX HFMG3 und MPX > FrSky Telemetrie Konverter

[DeletedUserReAsG]

Mit Verlaub: mir scheint, du drehst es dir so zurecht, dass es in deine Ansicht passt. Soll kein Angriff sein, jedoch: das Debianpaket kommt ohne einen Hinweis, wofür es eigentlich gedacht ist (ist’s für Debian? Welches Release? Ist’s für Buntu? Welches? Oder ist’s für irgendeines der Derivate (der Derivate (der Derivate)))? Keinerlei Angaben. Es stehen immerhin noch ein paar Abhängigkeiten in der control, aber die sind unvollständig → ein ordentliches Debianpaket sieht anders aus.

Auf der anderen Seite, mit deinen Worten: es braucht auch kein Arch-Paket, denn OpenTX liefert schon noch viel länger die Sourcen aus, mithilfe derer es sich komplett automatisiert aus dem AUR bauen lässt – und zwar für das konkret vorliegende System, nicht für irgendeines, wobei es dann nur zufällig auf dem Vorliegenden nutzbar ist. Und im Gegensatz zu dem dort angebotenen *.deb lässt’s sich dann auch noch automatisch über die Paketverwaltung up to date halten.

Hab mir gerade eben mal das Durcheinander bei der Arduino IDE in der Aur angeschaut. Nein danke!

Wenn es dir als Durcheinander erscheint, dann solltest du’s gar nicht nehmen – das ist für Leute, die wissen, warum sie ihre IDE von dort beziehen wollen, und für die ist’s dann auch kein Durcheinander. Für alle Anderen gibt’s die aktuelle Version in den regulären Repos:

Code: Alles auswählen

niemand@NUC ~ % pacman -Ss arduino
community/arduino 1:1.8.15-1
    Arduino prototyping platform SDK
community/arduino-avr-core 1.8.3-1
    Arduino AVR core with upstream avr-gcc and avrdude
community/arduino-builder 1.6.1-1
    A command line tool for compiling Arduino sketches
community/arduino-cli 0.18.3-1 (arduino)
    Arduino command line interface
community/arduino-ctags 5.8_arduino11-4
    A mix of ctags and anjuta-tags for the perfect C++ ctags
community/arduino-docs 1.6.6-7
    Arduino IDE reference documentation

Das sieht zumindest für mich doch alles andere, als durcheinander aus. Und nun gucken wir wieder zu Debian: https://packages.debian.org/search?keyw ... ection=all – es fällt auf, dass das gar nicht so unterschiedlich aussieht. Und dass in Debian auch in Testing eine veraltete Version vorhanden ist.

Was das AUR angeht, so ist dessen Qualität nunmal naturgemäß durchwachsen: das U steht für User, und man muss keine Sachkundeprüfung ablegen, bevor man dort PKGBUILDs zur Verfügung stellen darf. Dadurch findet man dort immer was, worüber man den Kopf schütteln kann – allerdings ist’s höchst unfair und eigentlich grob falsch, damit das AUR gegen Debians Mainline-Repos ausspielen zu wollen. Entweder: offzielle Repos gegen offizielle Repos, oder User-Repos gegen User-Repos. Und bei Debian gibt’s Letzteres (noch) gar nicht, insofern leuchtet’s mir nicht direkt ein, was du da überhaupt vergleichen möchtest.

OT: AUR ist ein Akronym („Arch User Repository“), und wird daher durchgängig groß geschrieben

FrSky nutzt in aktuellen Sendern aber nicht mehr OpenTX, oder? Interessanter ist ja eigentlich auch, was du am anderen Ende hast – denn so’n Sender ist ja kein Selbstzweck. Parkflyer? Schaumgleiter? Oder was Klassisches, aus Balsa und Spannpapier? Oder was mit großem, waagerechten Rotorkreis? Vielleicht gar was mit mehreren kleinen, waagerecht angebrachten Propellern?

[kalle123]

Wir weichen etwas vom Thema ab

Zu den openTX deb Paketen. Bin seit 2014 bei openTX und bisher gut mit den dortigen Paketen gefahren. Gebe aber zu, mache vorab eine Probeinstallation in eine VM meines Debian BS.

Mit Verlaub: mir scheint, du drehst es dir so zurecht, dass es in deine Ansicht passt.

Machen wir das nicht alle hin und wieder mal?

Zu der Arduino IDE. Hab schon lange aufgegeben, da bei den Debian Paketen nachzuschauen.

Über Wheezy, Jessie, Stretch und Buster zog sich da immer 1.0.5 (uralt). Hab gerade mal geschaut und oh Wunder, bei Bullseye gibt es was neueres und Sid gar ist aktuell! Juckt nur nicht, ich lade mit tar.xz runter und entpacke die ins /Home Verzeichnis. Und gut isses. Ich bieg mir die Sache halt hin.

Wegen der Nachfrage, was ich so im Bereich Flugmodelle treibe, erlaube ich mir, mal ein paar Bilder zu posten.

Wenn ich mich hier auf dem Stuhl umdrehe. Ein Chinook II von R. Schweissgut (3. Rumpf mit 4. Fläche. Die Fläche (Vollbalsa) ist neu, die alte 3. hatte Verzug und damit flieg ich nicht!) Die roten Tesastreifen kommen noch runter. Dienen nur zur Einstellung der Ruder. Hab es ungern, wenn die Kiste beim 1. Start massiv zu Seite geht.

https://debianforum.de/forum/gallery/image/3242/medium

Drin ist da so was wie hier auf einem Testbrett. Arduplane für ein Delta.

https://debianforum.de/forum/gallery/image/3243/medium

Eine Etage höher unterm Dach. Der weiße Rumpf mit den roten Flächen ein ThermRES vom Scheibelhofer. Der gelbe Rumpf mit dem äußeren Flächenpaar ein MOUNTY von R. Schweissgut und der blaue Rumpf mit den gelben Flächen in der Mitte ein MILAN von Robbe.

https://debianforum.de/forum/gallery/image/3244/medium

Soviel dazu, aber ich baue gerne, nur wenn die Dinger einmal fliegen, interessiert mich das weniger. Bin auch kein begnadeter 'Richthofen'.

Gruß KH

[KP97]

https://linuxnews.de/2021/06/debian-erh ... genes-aur/

Wie bei allem, muß man auch hier abwägen, ob man sowas braucht. Ohne Ahnung vom Paketmanagement zu haben, würde ich das nicht empfehlen.