Du bist nicht angemeldet.

#1 29.05.2014 11:56:34

stefanhusmann
Moderator

AUR 3.0

Die Version 3.0.0 des AUR ist soeben freigeschaltet worden. Hinter den Kulissen hat sich einiges getan. So werden z.B. .AURINFO-Dateien unterstützt, die Metadaten der hochgeladenen Pakete enthalten.

Dies bringt mit sich, dass der Versuch, mit makepkg --source erzeugt Pakete hochzuladen, mit einer Fehlermeldung abgewiesen wird:

error: failed to upload bla-22.1.15.126.src.tar.gz: The source package does not contain any meta data. 
Please use `mkaurball` to create AUR source packages. Support for source packages without .AURINFO 
entries will be removed in an upcoming release! You can resubmit the package if you want to proceed anyway.

Das mkaurball-Skript ist Teil des Paketes 'pkgbuild-introspection' aus dem Community-Repo (naja, zur Zeit ist es der einzige Bestandteil).

Offline

#2 29.05.2014 13:15:06

Dirk
Moderator

Re: AUR 3.0

Ein paar mehr Infos wären geil smile Was kann die .AURINFO-Datei? Kann ich sie Manuell erzeugen? Braucht sie ’ne Checksummenangabe in der PKGBUILD? Etc.?

Offline

#3 29.05.2014 13:23:53

Pierre
Entwickler

Re: AUR 3.0

Leider verweist "Upstream" auch nur ins Git-Log: https://projects.archlinux.de/aur.git/log/?id=v3.0.0

Ich verfolge die AUR-Entwicklung kaum, aber soweit ich weiß, ist die neue META-Daten-Datei nötig um z.B. "Split Packages" zu unterstützen. Das Problem ist, dass PKGBUILDs reguläre Bash-Scripte sind, welche wir aus u.a. Sicherheitsgründen nicht auf dem Server ausführen können. Daher passiert dies auf dem Client und es wird eine AURINFO mit statischen Meta-Daten erzeugt.

Offline

#4 29.05.2014 13:25:51

stefanhusmann
Moderator

Re: AUR 3.0

Ich poste mal ein Beispiel.

pkgbase = sxemacs-git
	pkgdesc = A derivation of xemacs - git checkout
	pkgver = 22.1.15.126.g04168e3
	pkgrel = 1
	url = http://www.sxemacs.org/
	install = sxemacs.install
	arch = i686
	arch = x86_64
	license = GPL
	makedepends = git
	makedepends = texinfo-legacy
	depends = libpng
	depends = libao
	depends = gpm
	depends = libtiff
	depends = libjpeg
	depends = libltdl
	depends = libxpm
	depends = jack
	depends = libmad
	depends = desktop-file-utils
	depends = compface
	depends = libpulse
	depends = libxaw
	depends = openmotif
	depends = postgresql-libs
	provides = sxemacs
	conflicts = sxemacs
	conflicts = xemacs
	source = git+http://git.sxemacs.org/sxemacs
	options = !libtool

pkgname = sxemacs-git

Die Datei dient dazu, Metainformationen über das Paket für die AUR-Software bekannt zumachen, ohne dass diese das PKGBUILD parsen muss, was gefährlich wäre. Kurz gesagt, klamüsert man die Infos aus dem PKGBUILD in "Schlüssel=Wert"-Pare auf.

Checksummenangaben werden, wie man an dem Beispiel sieht, offenbar nicht benötigt. Es handelt sich hier allerdings auch um ein -git-Paket.

Erzeugt wird diese Datei eben mit dem mkaurball-Skript.

Offline

#5 29.05.2014 13:33:34

Dirk
Moderator

Re: AUR 3.0

stefanhusmann schrieb:

Die Datei dient dazu, Metainformationen über das Paket für die AUR-Software bekannt zumachen, ohne dass diese das PKGBUILD parsen muss, was gefährlich wäre.

Also redundantes Vorhalten von Informationen ohne echten Mehrwert? Die Problematik des Parsens könnte man mit einem vernünftigen Parser umgehen, aber einfach eine weitere Datei dafür zu erzwingen, ist natürlich einfacher …

Schade, ich dachte, das AUR könnte endlich ähnlich wie z.B. GitHub mehr informationen als das aus pkgdesc zur Paketbeschreibung anzeigen.

Offline

#6 29.05.2014 13:38:27

Pierre
Entwickler

Re: AUR 3.0

Dirk, wie würdest Du einen vernünftigen Bash-Parser schreiben? Bedenke, dass PKGBUILDs alles mögliche an externen Tools aufrufen kann wie sed, awk etc.. Einzige Lösung wäre eine robuste Sandbox; da hat man aber schnell Ressourcen-Probleme etc.. Das ist kein triviales Problem.

Offline

#7 29.05.2014 13:52:28

Dirk
Moderator

Re: AUR 3.0

Pierre schrieb:

Dirk, wie würdest Du einen vernünftigen Bash-Parser schreiben? Bedenke, dass PKGBUILDs alles mögliche an externen Tools aufrufen kann wie sed, awk etc.

So wie ich das sehe, ist das nur für die Metadaten relevant. Und was bitte macht das AUR mit Bash? Ein simples grep in Kombination mit sed ist völlig ausreichend, um aus dem PKGBUILD alle relevanten Metadaten zu extrahieren. Da wird dann auch nichts geparst.

Offline

#8 29.05.2014 14:01:07

Pierre
Entwickler

Re: AUR 3.0

Nein, nur mit sed und grep wirst Du keinen Bash-Parser bauen können. Ähnliches war ja bereits vorhanden und hat nicht in allen Fällen funktioniert. PKGBUILDs sind keine statischen Daten sondern ein Programm. Die Meta-Daten sind der Inhalt bestimmter Variablen nachdem das Programm gelaufen ist.

Als Denkaufgabe parse mal die Abhängigkeiten von z.B. dem Steam-PKGBUILD mit grep und sed: https://projects.archlinux.de/svntogit/ … ages/steam

Und da gibt es noch mehr, komplexere Beispiele.

Ich finde die AURINFO-Lösung auch alles andere als elegant. Allerdings scheint mir dies zur Zeit die einfachste und stabilste Lösung zu sein. Wollen wir mal nciht so tun, als ob sich die Entwickler hier keine Gedanken zu gemacht haben.

Offline

#9 29.05.2014 14:12:13

Dirk
Moderator

Re: AUR 3.0

Pierre schrieb:

Allerdings scheint mir dies zur Zeit die einfachste und stabilste Lösung zu sein.

Wäre nicht langfristig ein Umdenken von „Das PKGBUILD ist ein Programm“ hin zu „Das PKGBUILD ist eine Informationsdatei“ sinnvoll, wobei die Bau-Schritte dann in einzelne Dateien aufgeteilt werden können?

# PKGBUILD
[package]
pkgname = "foo"
description = "Mein tolles Paket"
version = 1.2.3
rel = 1
arch = x86_64;i686
[usw.]

… und dann eben z.B. BUILDPKG für den Bauprozess, etc.?

Da hätte man nicht nur ein standardisiertes System (PKGBUILDs muten teilweise wie der SysVinit-Daemonscript-Wildwuchs an), sondern könnte auch gefahrlos die PKGBUILD parsen, um, an die Metainfos zu kommen.

Offline

#10 29.05.2014 14:45:29

stefanhusmann
Moderator

Re: AUR 3.0

Ich fürchte, dann wäre Arch nicht mehr Arch. Dass man mit derselben Herangehensweise ein Paket aus den offiziellen Repos und aus einem User-Repo AUR bauen kann, ist m.E. eines der großen Vorteile von Arch.

Wobei es für deinen Ansatz, Dirk, bestimmt auch gute Gründe gäbe. Und vermutlich auch Befürworter (liest Xyne hier mit?)

Offline

#11 29.05.2014 14:49:30

Dirk
Moderator

Re: AUR 3.0

stefanhusmann schrieb:

Ich fürchte, dann wäre Arch nicht mehr Arch. Dass man mit derselben Herangehensweise ein Paket aus den offiziellen Repos und aus einem User-Repo AUR bauen kann, ist m.E. eines der großen Vorteile von Arch.

Was spricht dagegen, den Prozess aus den Repos entsprechend zu verbessern, und das AUR dann daran anzupassen? (Gut, außer, dass es ein Arsch voll Updates nach sich ziehen wird *g*)

Offline

#12 29.05.2014 14:52:08

efreak4u
Mitglied

Re: AUR 3.0

Dirk schrieb:

...(Gut, außer, dass es ein Arsch voll Updates nach sich ziehen wird *g*)

Hat die filesystem-Umstellung im letzten Jahr auch. Wir haben es, bis auf wenige Ausnahmen, ueberlebt. ^^

Offline

#13 29.05.2014 14:53:13

Dirk
Moderator

Re: AUR 3.0

efreak4u schrieb:
Dirk schrieb:

...(Gut, außer, dass es ein Arsch voll Updates nach sich ziehen wird *g*)

Hat die filesystem-Umstellung im letzten Jahr auch. Wir haben es, bis auf wenige Ausnahmen, ueberlebt. ^^

Ja, eben! big_smile Und wenn man hinterher ein leicht zu erweiterndes System hat, das zudem auch noch vom Konzept her alleine schon sicherer wird, spricht doch nichts dagegen, oder?

Offline

#14 10.06.2014 01:55:56

stefanhusmann
Moderator

Re: AUR 3.0

Das Problem wäre weniger ein Arsch von Updates für die User, sondern ein Haufen Arbeit für die Developer - und das nur, damit das AUR schöner und besser wird?

Einige der Developer benutzen noch nicht einmal [community], da werden sie wohl kaum das AUR als Triebfeder anerkennen, und dafür jahrelang gepflegte, bewährte und funktionierende Workflows umstoßen.

Nein, das AUR muss sich aus sich selbst heraus ändern und entwickeln. Die derzeitige Methode mit dem mkaurball-Skript ist übrigens übergangsweise zu sehen. Die nächste größere Änderung wird dem Vernehmen nach die Einführung von git-Repos pro Paket sein. Dann werden gar keine Tarballs mehr hochgeladen, sondern git-Pushs gemacht.

Offline

#15 10.06.2014 06:12:39

Dirk
Moderator

Re: AUR 3.0

stefanhusmann schrieb:

… und das nur, damit das AUR schöner und besser wird?

Bitte noch mal genau lesen. Dass das AUR besser wird, ist nur ein Nebeneffekt. Das gesamte Paketsystem würde dadurch besser werden. Dass das AUR von den meisten Devs abgelehnt wird, ist mir schon klar.

Offline

Schnellantwort auf dieses Thema

Schreibe deinen Beitrag und versende ihn
Deine Antwort

Fußzeile des Forums