Ovion schriebHi Leute,
bin erst vor kurzem auf ArchLinux umgestiegen und momentan munter am experimentieren.
Dann Willkommen!
Ovion schrieb
1) Wann genau (gerne auch exemplarisch) ist das ABS von Nutzen?
a) Für die Entwickler/Paketbauer natürlich, die uns damit ohne eigene Arbeit wunderschön kompilierte Binärpakete zur Verfügung stellen ;-)
b) Als Quelle für mich, so kann ich (offline) nachschauen wie und mit welchen Optionen ein Paket gebaut ist.
c) Wenn ich ein Paket aus den Repos mit anderen Optionen bauen will/muß als es der Entwickler/Maintainer für die Distribution macht. Durch ABS kann ich das recht simpel erledigen und muß nicht am Paketmanagement vorbei arbeiten.
d) Wer leicht paranoid ist und dem Entwickler/Maintainer/Paketbauer nicht traut...
Generell (egal ob ABS oder das AUR) hat Archlinux ein recht "simpel"(sic!) gestricktes Paketbauformat, was es auch Anfängern ermöglicht, statt gegen die Paketverwaltung zu arbeiten, diese eben zu nutzen.
Selbstkompilieren für "Geschwindigkeit" macht IMHO unter Archlinux recht wenig Sinn, das Endprodukt wird nicht groß anders/schneller/schöner sein. Anders wäre es ggf. nur, wenn die Default-Compileroptionen und die ganzze Toolchain z.B. noch i386, i486er berücksichtigen würden. Aber so müßte IMHO ein spezielles Prog. schon einen "riesigen" Geschwindigkeits/Stabilititätszuwachs erzielen durch Selbstbauen damit der Aufwand dazu gegengerechnet werden könnte. Ganz zu Schweigen davon, wenn man dafür auch noch den ganzen "Rest"(bash, find, libreoffice(!)) mitbauen muß weil die Distribution das so "verlangt".
Ovion schrieb
…ABS nicht ganz so mächtig sein soll, wie bspw. die Möglichkeiten von Gentoo…Gerade die USE-Flags sollen unter dem ABS nicht verfügbar sein…
Letztendlich wird bei beiden Distributionen irgendwann ein "configure, make install" gestartet… Die USE-Flags sind ja eine Zwischenebene im Gentoo-Buildprozeß, hier parst das Gentoo-Pendant zu makepkg andere Steuerdateien aus deren Informationen er bestimmte configure/make-Optionen "vorbelegt".
Das ist eine feine Sache wenn man z.B. durch ein Flag "no-pulseaudio" den Buildvorgang anweisen kann, jedes zu bauende Paket, welches eine Wahlmöglichkeit eben für pulseaudio-Unterstützng hat, eben ohne diese zu bauen. Bei Archlinux müßte ich in jedes PKGBUILD "reinschauen/ändern" wenn ich das erreichen wollte.
Ein gutes Beispiel für Vorteil der USE-Flags ist IMHO das alte KDE 3.x gewesen. Der Sound-Daemon artsd war dort ein "Quell der Freude", durch entsprechende USE-Flags ließ sich unter Gentoo nun recht unkompliziert eine KDE-Umgebung/Tools bauen eben ohne artsd-Unterstützung (wenn möglich).
Diese generalisierten "Flags" nehmen dem User also Arbeit ab und lassen ihn recht gezielt Einfluß auf Kompiliervorgänge etc. nehmen. Aber mal ehrlich: Das nützt v.a. dem, der gezwungen ist sein ganzes System selbst zu bauen. Klar, dieser profitiert von kürzeren Compiler/Linkerzeiten durch gezieltes Weglassen, spart u.U. auch Platz (kleinere Pakete) und erhält evtl. auch etwas schnellere (meßbar?) Binärprogramme - aber auf einem Single-Rechner wird jedes Quentchen gewonnene Geschwindigkeit durch nur einen Buildvorgang von Open/Libreoffice wieder aufgefressen werden....
Also kurze (meine Meinung): Sowas wie USe-Flags sind schön für die, die meinen ihr System selbst bauen zu müssen (oder von der Distribution/OS dazu angehalten werden da es ein wesentliches Feature derselben ist). Ich hingegen bin froh, daß andere für mich die Arbeit machen (dafür nehme ich gerne mehr HD-Speicherplatz hin) - und ich kann immer bei Bedarf über ABS/AUR (PKGBUILD und makepkg) eingreifen wenn ich es für nötig erachte…