Das Portsystem an sich ist wahnsinnig kompliziert und wird mit jedem neuen Feature nur noch komplexer gemacht. Darum hat man eine Bürokratie gebaut, die jeden preußischen Beamten neidisch machen würde. Und im gleichen Atemzug beschwert man sich, dass niemand mehr mitspielen will, es immer weniger Committer und Port Maintainer gibt.
Ich stimme zu was das Thema Komplexität angeht. Ich möchte aber auch hervorheben, dass das wenn ich es mit der Linuxwelt vergleiche eher auf der Tatsache basiert, dass die Komplexität von diversen Ports höher wird. Der Weg configure und make install funktioniert immer seltener. Der Unterschied den ich da eher sehe ist, dass man in der Linuxwelt für jeden "Port" (spec, PKGBUILD, etc.) das Rad komplett neu erfindet und ständig überall was bricht weil der Hack dann nicht mehr richtig funktioniert.
Ein anderer Punkt ist auch, dass sich die Komplexität teilweise nur verlagert. Vieles an Information ist nämlich eher Metadatenmäßig aufgebaut. Das beginnt so langsam mit pkg. Ich hätte nur ungern, dass die FreeBSD ports sich in eine Richtung entwickelt, wo jeder Port (oder halt das Spec dann) ein Problem das viele Leute haben ganz anders löst.
Zum Thema Port Maintainer: Stimmt das? FreeBSD hat für echt alles einen Port und die Ports sind aktuell und als jemand der auch gern Commit Messages liest sehe ich dass es sowohl einige Mentoren zu geben scheint, als auch, dass es coole Verbesserungen, wie Flavors gibt.
Ich habe ziemlich lange Arch Packages gemacht (mittlerweile nicht mehr, weil ich kaum noch dort unterwegs bin). Das System ist eher simpel, aber auch da fließt Komplexität ein und ständig bricht was und es gibt alle paar Monate einen neuen Standard wie man es richtig machen sollte, der auf viele Fälle nicht zutrifft und dann kommt's drauf an wie aktiv der Maintainer ist, ob er sich dran hält und welche Version von dem was gerade Best Practice ist eingehalten wird.
Das wird zwar besser, aber eher dadurch, dass man sich da etwas dem was FreeBSD macht annähert.
Ich bin mir nicht sicher, was du mit Bürokratie meinst, aber falls du damit meinst, dass dieses ganze Zeug, wie GH_user und so an Formulare erinnert, dann hat das den großen Vorteil, dass dann eine Verbesserung gleich auf alles zutrifft und gefühlt (ist ja glaube ich ohnehin eher subjektiv) eher weniger böse Überraschungen gibt.
Man könnte einfach mal einen idiologiefreien Blick ins Linux-Lager werfen. Mein Vorschlag ist so schon seit längerem, habe ich auch schon mehrfach an anderen Stellen zur Diskussion gebracht: Schmeißt das ganze verdammte Port-Framework in den Müll. Die Ports sollten nur noch formale Beschreibungen ohne jegliche Programmlogik sein. Die Logik steckt im Package-Builder, der die formalen Beschreibungen parst. Wer sich einen Port zum Paket compilen will, muss sich dann halt den Package-Builder installieren. Das wäre für Port Maintainer von Vorteil, weil der Package-Builder eine saubere Umgebung bereit stellt und all die Probleme durch verharzte Hostsysteme wegfallen. Außerdem würde neue Funktionalität einfach im Package-Builder implementiert werden können, Änderungen an den Ports selbst wären nur noch selten oder sogar gar nicht mehr notwendig. Auch könnte man den Package-Builder in einer geeigneteren Sprache als den paar tausend Zeilen Makefile implementieren, aus dem das Port-Framework besteht.
Ich glaube ich weiß worauf du hinaus willst. Die Sache ist nur, dass ich ständig Systeme die rein deklarativ und ohne Programmlogik sind im großen Stil zusammenbrechen und erst wieder irgendwo anders, meist viel hackiger Logik brauchen. Ja, ich habe auch lieber Sachen, wo ein deklarativer Ansatz möglich ist. Ich habe aber auch gesehen, wo es scheitert und wie es weitaus grausiger ist ein System, das theoretisch perfekt wäre einfach ständig auf Koalitionskurs mit der Realität ist. Ein System, das derart abhängig vom Rest der Welt ist und darauf keine wirkliche Auswirkung hat mit einer simplen Beschreibungssprache versehen zu wollen halte ich nicht für eine gute Idee. Das würde funktionieren, wenn Leute anständige Software, einheitliche Build Systeme und einfach saubere Projekte führen würden, oder da zumindest bei der großen Mehrheit der Fall wäre und sich vielleicht die Welt generell in diese Richtung bewegen würde. Das ist aber (leider) nicht der Fall.
Das Resultat ist eben, dass entweder die Komplexität verschoben wird und man so generisch werden muss, dass man zumindest erlaubt erst wieder mit Programmlogik reinzupfuschen oder man eine Beschreibungssprache braucht, die relativ schnell Turing Complete ist (oder nah dran) und mit der sich dann wirklich nur ein paar Leute auskennen, was wiederum zu Mangeln an Committern führt.
Da finde ich den Ansatz so etwas über eine Skriptsprache mit Ports, die möglichst deklarativ aussieht, wo das auch sinnvoll möglich ist (quasi alles was mit configure && make install, etc. funktioniert) den besseren Ansatz. Ich finde auch, dass er ziemlich gut funktioniert, wenn ich das nüchtern auch mit Linux-Systemen die ich grundsätzlich mag vergleiche. Ich brauche nicht ständig irgendwelche Third Party Repos zuschalten, nicht großartig dem package manager irgendwelche Configs übergeben (oder das irgendwie anders konfiguieren) oder irgendwelche Änderungen an den.. ich nenne es mal "Ports" (sprich das Pendant dafür) machen und mir potentiell relativ Mühsam ein eigenes Repo zuschalten. Für die Anzahl an Leuten, die dahinter steht würde ich Ports eigentlich als ziemlich gut bezeichnen. Selbiges würde ich über diverse andere Projekte nicht behaupten. Allerdings rede ich da von ein paar großen Systemen (RedHat, Arch, Debian), die ich so einigermaßen gut kenne. Die sind zwar nicht schlecht oder ähnliches, aber für das was da an Leuten dahinter steht kommen die glaube ich kaum ran. Es gibt sicher Projekte, wo das besser funktioniert. Auch würde ich sagen, dass Arch da wesentlich bessere Arbeit leistet als noch vor einigen Jahren (nicht nur was AUR betrifft!).
Auf der Grundlage könnte man den ganzen ganzen Workflow ändern. Port Maintainer laden ihre Änderungen an Ports über ein Webinterface hoch. Ist der Maintainer neu, guckt über die ersten 5 oder so Einreichungen ein Committer rüber und klickt auf "freigeben". Hat er sich bewährt, fällt dieser Schritt weg, die Änderungen werden automatisch in ein "Testing"-Repo eingefügt und gebaut. Klappt der Bau und klickt innerhalb von 3 Tagen kein Nutzer auf "Hier gibt es ein Problem", migriert die Änderung automatisch ins normale "Latest"-Repo. Der Maintainer kann festlegen, ob sie nach weiteren 3 Tagen wieder automatisch in "Quarterly" migrieren. Das würde die Committer massiv entlasten und den Prozess wesentlich transparenter und zügiger machen, was sicher wiederum viele Nutzer begeistern würde auch mal Maintainer zu spielen.
GitHub und Pull Requests könnten das auch leisten und man könnte wohl auch relativ einfach für einzelne Ports ein ähnliches System machen. Ich stimme zu, dass das System so wie es ist einigermaßen ineffizient ist, aber ich denke dass das mehr ein Problem des Prozesses ist, der bei einer Umstellung wohl auch von technischen Umstellungen profitieren würde, aber ich habe da meine Zweifel, dass man da mit rein (oder hauptsächlich) technischen Änderungen einen großen Wurf hinbekommt.
Aber wie gesagt, mit solchen Vorschlägen braucht man gar nicht zu kommen. Ich habe es ein paar Mal versucht, mit wesentlich weniger radikalen Varianten und die Reaktion war jedes mal ein unfreundliches "Geh wo du wohnst!".
Das lässt mich noch mehr denken, dass es generell ein eher menschliches Problem ist, als wirklich ein technisches. Ganz ehrlich macht mich die Community auch teilweise ziemlich unglücklich. Ich schreibe zwar nicht, aber lese durchaus auch mit. Leider sind mir mittlerweile ein paar Communities dadurch aufgefallen, dass sie zunächst nachwuchsfördernd auftreten, aber dann oftmal sehr reserviert ist, dass es teilweise zumindest stark an Statusdenken und Revier verteidigen erinnert. Das dürfte häufig auch vor allem von Leuten ausgehen, die noch nicht allzu lange in einer Community aktiv sind und sich quasi gerade erst die volle Mitgliedschaft (also Core Team, Commit Bit, etc.) erarbeitet haben.
Im Übrigen soll das da oben nicht heißen, dass ich denke es sei alles gut, perfekt oder bedürfe keiner Veränderung. Auch glaube ich, dass du das eher überschlagsartig beschrieben hast. Mir ging's vor allem darum zu sagen, dass auch wenn ich selbst denke, dass man Logik im besten Fall an vielen Orten raus halten soll und auch, dass viel zu wenig auf Trennung geachtet wird, man bei manchen Dingen eher einfährt. Ich habe das selbst ein paar mal gemacht und häufig hat es damit zu tun, dass man vergisst, wie weit weg die Welt (und hier ist es eben die gesamte Welt, weil Third Party) von einem Status ist. So etwas muss man irgendwie erzwingen können. Das geht dann eher einfach wenn man eine große Firma (Facebook, Apple, Google, ...) ist und Geld dahinter steckt. Ansonsten wird es schwierig. Und dann soll das ja auch noch Software unterstützen die so halb-tot ist. Ich sehe deshalb in dem Fall ein deklaratives System nicht funktionieren. Ich glaube da muss man eher einen Mittelweg finden und da ist die Tatsache, dass sich die Ports zumindest generell in eine Richtung entwickeln, die schon nah an simple Beschreibung kommt schon mal nicht schlecht.
Vielleicht wird vieles mit dem Ausbau von Lintern und ähnlichem besser. Da habe ich ehrlich gesagt schon Hoffnung, dass man dann für vieles kaum noch einen Unterschied hat außer ein paar kleine Hinweise, dass es doch Makefiles sind.[/QUOTE][/QUOTE]
) sparen und motivierte Programmierer heranzüchten. Und wir profitierten von nativem Steam, vielleicht eines Tages Photoshop etc...?
Wie seht Ihr das?
