Zukunft von FreeBSD-Ports ohne Maintainer

[pit234a]

Hi.
Es ist mir gerade bei den Experimenten in den letzten Tagen mit verschiedenen Browsern
( http://www.bsdforen.de/threads/welchen-browser-nutzt-ihr-und-warum.32074/page-3 ff )
mal wieder aufgefallen, dass es zahlreiche verwaiste Ports gibt.
Zumindest erklären viele Ports etwas in der Art:

===>   NOTICE:

The XYZ port currently does not have a maintainer. As a result, it is
more likely to have unresolved issues, not be up-to-date, or even be removed in
the future. To volunteer to maintain this port, please create an issue at:...

Weil ich FreeBSD als Basis zu meinem Desktop nutze, dabei viele Ports einsetze und auch noch unabhängig von irgendeinem speziellen DesktopEnvironment bleiben möchte, frage mich mich natürlich schon, was das denn für die Gegenwart und vor allem für die Zukunft bedeuten kann.

Gibt es heute schon Mechanismen, die einen Maintainer quasi ersetzen? Oder ist ein verwaister Port notgedrungen nicht aktuell und wird auch nicht laufend aktualisiert, sondern hängt bei der letzten aufgearbeiteten Version?

Auch mit solchen Mechanismen wird das sicher nicht auf Dauer gut gehen und irgendwann braucht es einen Maintainer und wenn es den nicht gibt, werden dann konsequenterweise immer mehr Ports verschwinden?
Ich fürchte das ja.

Und das bedeutet dann ja auch, dass sich das Angebot an Ports und Paketen auch bei FreeBSD immer mehr einem gewissen Mainstream annähern wird und dieser ist nun mal von den Überzeugungen mancher großer Distributionen im Linux-Lager maßgeblich geprägt, die dann vor allem auch noch auf die großen Vorbilder aus der proprietären Welt schielen. Kurz gesagt: diese Entwicklung würde dann nicht zu meinen Vorstellungen und Wünschen passen.

Dabei sehe ich zwei Modelle.
-Einmal kann es sein, dass ein Port auch deshalb verwaist, weil er einfach uninteressant geworden ist, die SW nicht mehr weiter entwickelt wird und brach liegt. Dann wird es diesen Port auch für ein GNU/Linux bald nicht mehr geben. Wir haben das in der Vergangenheit häufig erlebt und zwar auch bei einigen ganz nützlichen Beispielen, dass die Entwickler einfach keine Lust mehr hatten (nicht mehr konnten, nicht mehr wollten oder was auch immer) und deshalb ihre Arbeit komplett aufgaben.
-Aber, es kann ja auch sein, dass die SW durchaus weiterentwickelt wird und einfach nur für FreeBSD keine Unterstützung mehr möglich ist, weil wir hier nicht genug fähige Mitarbeiter generieren können.

Darüber mache ich mir so meine Gedanken und verstehe davon zu wenig, um mir ein Urteil zu bilden.

 

[zuglufttier]

Wenn ein Port irgendwann, aus welchen Gründen auch immer, nicht mehr funktioniert, dann fliegt er halt raus.

 

[Yamagi]

Das erscheint dramatischer, als es ist. Eben weil nun seit einiger Zeit diese Meldung kommt... Über längere Zeit gesehen schwanken diese Dinge um einen recht konstanten Mittelwert; Gesamtanzahl Ports, Anzahl defekter Ports und so weiter sind also relativ gleichbleibend. Und die Erfahrung sagt: Wenn ein Port aktive Nutzer hat, findet sich auch Maintainer.

 

[pit234a]

Das erscheint dramatischer, als es ist.

Ja, es wirkte wie ein verzweifelter Hilferuf auf mich und beunruhigte mich deshalb auch.
Nunja, es ist schließlich auch beunruhigend zu sehen, wie viele Ports das alleine schon bei mir sind, die solche Meldungen auswerfen.

Dass es jedoch keine veränderte Situation ist, sondern nur die neuen Texte darauf aufmerksam machen, das beruhigt mich schon wieder.

 

[Elwood]

Ist es schon schade, wenn Ports rausfliegen oder nicht mehr supported werden. Die einzige Lösung ist die, dass wenn man den/die Ports erhalten möchte, sich im Zweifel selbst als Maintainer einsetzt

 

[h^2]

Also als jemand der FreeBSD jetzt >15Jahre benutzt, muss ich sagen, dass die Ports in einem besseren Zustand sind, als ich sie je erlebt habe. Und vor allem die Pakete, das ist garkein Vergleich zu früher. Es gibt zwar ein paar Ausnahmen, zB sind die KDE-ports gerade sehr alt, aber ich habe gehört, das soll sich bald bessern...

Meines Erachtens würde die Ports nochmal spürbar einen Sprung machen, wenn man aufhören würde dieses absurde System von shar/patch + bugzilla zu nutzen. Man muss ja nicht github.com nutzen, eine selbst-gehostetes gitlab würde es auch tun. Clone und pull request machen ist einfach ein work flow den inzwischen sehr viele Menschen verstehen und ein interface mit vernünftiger Darstellung der Patches und dann noch eine automatische Test-Infrastruktur bewirken Wunder
Ich weiß, dass ich auf jeden Fall öfter beitragen würde, wenn der Workflow besser wäre

 

[Yamagi]

Wenn wir schon am Meckern sind, hätte ich noch meine ketzerische Meinung zum Aufbau der Ports:

Ich habe in der letzten Zeit einige Software für verschiedene Linux-Distros paketieren müssen. Das ist zwar zu Beginn etwas gewöhnungsbedürftig, aber schon nach dem zweiten Paket wesentlich angenehmer und eingängiger, als FreeBSD Ports es je waren. Egal, ob man mit dpkg, rpm oder pacman spricht. Unter dem Strich liegt es daran, dass die Ports ein riesiges, gigantisches und völlig unüberschaubares Framework sind und Nutzer auf jedem System ein "cd /usr/port/kategorie/port && make install clean" erlauben, wohingegen die Linux-Paketmanager diesen Anspruch auf universelle Einsetzbarkeit einfach nicht haben. Dort hat man lediglich formale Beschreibungen, ohne viel Gedöns und Intelligenz außen herum. Aus diesen Beschreibungen baut der separate Package Builder - und wirklich nur der Package Builder - das Paket, was man sich dann installiert.

Würde sich FreeBSD von den Ports verabschieden und wie die meisten Linuxe einfach zentrale Package Builder verpflichtend machen, könnte einiges an Komplexität wegfallen und das Erstellen von Paketen einfacher werden. Der Preis wäre allerdings, dass man sich nicht mehr schnell mal einen Port durchbauen kann, sondern erst einmal seinen lokalen Package Builder anwerfen muss. OpenSUSEs OBS bietet da allerdings eine gute Lösung, indem es den Package Builder für jeden zugänglich in die Cloud verfrachtet.

 

[-Nuke-]

Ich schließe mich da h^2 an.

Neben dem ist da halt auch noch die recht... ich sage mal "umfangreiche"... Syntax der Makefiles ein ziemlicher Stein im Weg für mich. Diese maximale Konfigurierbarkeit der Ports hat halt auch so seine Schattenseiten. Bestimmte Konstellationen bauen zum Teil nicht mal. Als Beispiel mal Samba das mit bestimmten OPTIONS nicht mehr baut. Bug im Makefile finden? Viel Spaß. >500 Zeilen langes Gewusel aus .if Bedingungen.

Die PKGBUILD Dateien von ArchLinux sind dagegen das reinste Kinderspiel. Im Endeffekt das was ich beim manuellen bauen auch selbst ins Terminal tippen würde. Wenig Automagie.

Ansonsten hier und da auch andere Probleme. So ist es z.B. so, dass PostgreSQL entgegen der Empfehlung der Entwickler nach /usr/local/bin installiert wird. Um PostgreSQL aber zu aktualisieren benötigt man die aktive und die neue Version parallel installiert. Das ist mittels pkg aber unmöglich zu erreichen. Der Maintainer möchte dies aber auch nicht ändern "weil es schon immer so war und alte Vorgehensweisen nicht ändern will"...

Auch wenn aktiv nach Mithilfe gefragt wird... es ist schwer sich in dieser Umgebung einzufinden. Auch wenn ich kein Fan davon bin auf jeden Hype-Train aufzuspringen, aber im Jahr 2016 noch Arbeitsweisen von 1995 an den Tag zu legen spornt nicht an.

 

[KobRheTilla]

Auch wenn aktiv nach Mithilfe gefragt wird... es ist schwer sich in dieser Umgebung einzufinden.

Hmm, also ich habe in letzter Zeit auch an einigen Port-Makefiles gebastelt, und fand es jetzt so schlimm nicht. Es gibt mittlerweile viel Magie, die einem Deklarationsaufwand abnimmt. Das Samba-Makefile ist dafür ein gutes (oder eher schlechtes) Beispiel, es nutzt nämlich noch die alten Deklarationen und enthält somit eine Menge Bloat.

Beispiel:

.if ${PORT_OPTIONS:MAVAHI}
LIB_DEPENDS+=           libavahi-client.so:net/avahi-app
CONFIGURE_ARGS+=        --enable-avahi
.else
CONFIGURE_ARGS+=        --disable-avahi
.endif

Das ganze kann man mittlerweile auch so schreiben:

MAVAHI_LIB_DEPENDS=libavahi-client.so:net/avahi-app
MAVAHI_CONFIGURE_ENABLE=avahi

4 Zeilen weniger.
Man müsste sich nur mal ransetzen und aufräumen.

Rob

 

[m4rkus]

Ich schließe mich da h^2 an.
...
Ansonsten hier und da auch andere Probleme. So ist es z.B. so, dass PostgreSQL entgegen der Empfehlung der Entwickler nach /usr/local/bin installiert wird. Um PostgreSQL aber zu aktualisieren benötigt man die aktive und die neue Version parallel installiert. Das ist mittels pkg aber unmöglich zu erreichen. Der Maintainer möchte dies aber auch nicht ändern "weil es schon immer so war und alte Vorgehensweisen nicht ändern will"...

Geht dann leider nur über ein temporäres Jail mit den alten Binaries oder ich glaube über "PREFIX=/alternativer/pfad".

 

[-Nuke-]

Geht dann leider nur über ein temporäres Jail mit den alten Binaries oder ich glaube über "PREFIX=/alternativer/pfad".

Ja ich mache das dann auch über eine Jail, aber dieser mehrstufige Kram ist halt Mist. Poudriere mit neuer PostgreSQL Default-Version anwerfen, den rödeln lassen, Jail upgraden, Datenbank dumpen, Datenbank aktualisieren, Daten von Jail wieder reinschieben, statt einfach in einer Jail neben der alten Datenbank die neue zu installieren und dann pg_upgrade aufzurufen...

Generell ist diese starke Bindung der PostgreSQL Version an die Ports ziemlich störend. Ist nicht so als wenn libpq ständig seine API kaputt macht...

 

[Crest]

Also Ports haben einen riesigen Vorteil: ich kann Software selbst sauber einbinden und mit den Buildprozess beeinflussen. Ja Binärpakete sind ein gutes Endprodukt, aber ich es gibt zuviele mögliche sinnvolle Kombinationen als das sich für alle davon Binärpakete bauen lassen. Mit Ports kann ich mir das Tool meiner Wahl nehmen z.B. Poudriere und eigene Repos erstellen. Gerade bei Debian basierten Distros ist meist das hinzufügen weiterer Paketquellen der Anfang vom Ende. Als Maintainer fand ich die Ports bis jetzt sehr hilfreich. Ja manchmal muss man halt ein paarhundert Zeilen Makefiles lesen/überfliegen um zu verstehen wie etwas geht. Dafür muss ich mich nicht ständig Wiederholen sondern kann die meisten Probleme einmalig, kurz und deklarativ lösen.