Ich als User erwarte dass die Pakete sinnvoll sind, wer sich jetzt darum kümmert das die Pakete nun richtig gebaut werden ist mir herzlich egal. Wenn die Auten der Software dazu nicht in der Lage sind, dann sollten es die Distributoren tun. Denn was hilft es mir dass das Paket "verbatim" ist, wenn es meine Anforderungen nicht erfüllt? Das ist auch generell so ein Problem in Arch, um die Pakete möglichst wenig zu verändern werden komische Hacks genutzt, etwa erweitern des $PATH in der profile.d und mein $PATH enthält dann Pfade zum bin-ordner von Maven, Ant, Ruby, Perl, what-have-you und ich muss mich neu einloggen um diesen $PATH überall zu übernehemen. Statt ``/usr/bin`` für das zu nutzen wofür es ja auch da ist (Disclaimer: ich bin Arch-User und maintaine auch einige AUR-Pakete, unter anderem eine Prolog-Implementation. Aber ich muss ja nicht alles gut finden).naeg hat geschrieben:Was hat das mit der Qualität von Arch Linux Paketen zu tun?
Arch Linux will alle Pakete möglichst unmodifiziert an Upstream halten. Da SWI-Prolog keinen Symlink in /usr/lib (o.ä.) erstellt, gibts diesen symlink eben nicht. Wenn man mal kurz nachdenkt ist die Idee mit an Upstream halten nicht blöd
Naja, ob man sich deswegen die Nachteile von statischem Linken ins Boot holen will ist IMHO zweifelhaft. Und ab dem Punkt wo Pakete auf verschiedenen Architekturen verschieden bauen empfinde ich das nicht mehr als sonderlich schön. Finde besser wenn die Community-Pakete der "sinnvolle Kompromiss" sind, für Spezialwünsche wie höhere Performance oder Optimierungen (wie im Fall von firefox-pgo) gibt es ja das AUR.naeg hat geschrieben:Und das mit den shared libs: Es ist tatsächlich so, dass die x86 Version die shared lib nicht standardmäßig dabei hat, aber die x86_64 schon. Der Grund dafür ist, dass die x86 mit shared libs laut Entwickler ca. 10% langsamer ist.