Wer ist hier mit alten Werkzeugen in die FLAVOR Falle reingerannt?

Ich würde aber gerne den Overhead von Poudriere vermeiden.
Dito .
Gibt auch einen Eintrag in ports/UPDATING
Es geht aber, zumindest mit den py* Ports. Praktischerweise llistet portupgrade die betroffenen Ports am Ende auf als nicht auffindbar.
Diese mit 'make FLAVOR=py* -C /usr/ports/und/soweiter' gebaut hat bis jetzt bei mir alles gerichtet.
PS.: Erfahrungsbericht: Man nehme, 'american english' (=FLAVOR) und nicht 'british english' (=FLAVOUR).
 
Zumindest Portmaster ist damit wohl erstmal endgültig tot. Es wird ja schon länger nicht mehr aktiv weiterentwickelt und auch wenn es durchaus Interesse gab es weiterzuführen, hat sich bisher niemand gefunden, der sich ernsthaft an die Arbeit heran getraut hat. Und wenn ich mit den Quellcode von dem Ding so anschaue - 4366 Zeilen Shell-Script - wird es wohl eher auf einen Rewrite, als auf eine Anpassung hinauslaufen. Bei Synth sollten die Chancen wesentlich besser sein, einfach weil da jemand aktiv dran arbeitet...

Auf jeden Fall waren FLAVORS dringend notwendig und man hätte schon vor 5 Jahren etwas in die Richtung machen sollen. Daher ist es auch gut, dass man nun nicht noch länger darauf wartet, bis alle Tools angepasst wurden.
 
Stimme Yamagi zu. War mehr als nötig, vor allem wenn man seine Packages nicht selber baut. Also vielen Dank an alle Entwickler! Kann's für kleinere Systeme kaum erwarten, dass der nächste Build mit Flavors fertig ist. Leider waren beim letzten ein paar Posts, die interessant wären noch nicht umgestellt.

Hatte das Glück, dass poudriere schon einige Zeit vor der tatsächlichen Umstellung geupdated wurde. Schade, dass marino und andere scheinbar nicht wirklich informiert wurden. Angebahnt hat es sich ja schon eine Weile.
 
Ui, Portmaster ist tot? Hm, dann wird es wohl mal Zeit, sich mit synth zu befassen... Noch liegt der kleine Homeserver irgendwo in einen der Umzugskartons, aber...
 
Also im Vergleich zu portupgrade wirkt synth leider auf mich so gar nicht schlank. Mit
Code:
portupgrade -fu www/youtube_dl
kann ich innerhalb von Minuten, wenn nicht gar Sekunden eben mal www/youtube_dl neu bauen und reinstallieren.
synth wollte hingegen rund 300 Pakete neu bauen, was natürlich eher in Stunden gemessen werden will. Hat aber leider dann noch nicht mal www/youtube_dl neu bauen können, es scheitert an freetype2, überspringt dann 4 weitere Pakete und scheitert dann schlussendlich auch mit dem eigentlich nur gewollten www/youtube_dl neubauen und reinstallieren.

freetype2 bekommt hingegen portupgrade genauso problemlos gebaut wie youtube_dl. Ich würde also nur ungerne auf synth umsteigen müssen. Mag synth schlanker als poudriere sein, so ist doch das alte portupgrade noch mal sehr viel schlanker und für meinen Bedarf auf FreeBSD auch sehr viel schneller.

Natürlich ist Fertigpakete nutzen nochmals schneller, aber ich erlebe das ja auf Kubuntu, man wird in gewisser Weise auch weniger interessiert und zum Faultier. Das Selbstbauen hält hingegen das Interesse wach und ab und an gibt es dann auch mal ein Nüsschen zu knacken. So wie jetzt zum Beispiel beim Umbau der Ports Architektur mit FLAVOR. Als Fertigpaket Nutzer hätte ich mich einfach gar nicht weiter kümmern müssen, ich hätte es womöglich noch nicht mal mitbekommen, oder es hätte mir Jahre später vielleicht mal jemand beim plaudern erzählt.
 
Das heißt ich kann meine getrennte "DEFAULT_VERSIONS" poudriere Jails für Python 2 und Python 3 einstampfen und man kann einfach DEFAULT_VERSIONS python=3.6 setzen und es kracht nicht bei harten Python 2.7 Abhängigkeiten?
 
Schade, dass marino und andere scheinbar nicht wirklich informiert wurden.
Marino wurde der nicht aus dem FreeBSD Ports Team geworfen? Ist für ihn eigentlich Synch noch interessant? Der baut doch schon wieder am nächsten Projekt: ravenports. Poudriere ist halt das offizielle Buildsystem für die Ports. Man kann nicht erwarten, dass man immer und überall Rücksicht nimmt.
 
synth läuft unter DragonFly BSD angeblich noch besser als unter FreeBSD, insofern gehe ich schon davon aus, dass es jetzt nicht plötzlich verschwindet. Wobei das natürlich davon abhängt, was die "ravenports" flavormäßig zu tun gedenken.

Ich lasse synth upgrade-system gerade mal spaßeshalber laufen, habe aber noch nicht ganz verstanden, nach welcher Logik es entscheidet, welche Pakete aktuell sind und welche nicht. Zumindest scheint es p.d. Ähnliches zu tun wie portmaster -r. Sein Speicherverbrauch ist zum Speien, mehr als 1 "Worker" gleichzeitig wird irgendwann von FreeBSD abgeschossen - aber ich habe ja Zeit. Mal gucken, ob inkrementelle Builds nach dem ersten vollständigen Durchlauf schneller gehen. Ich lasse das mal über Nacht an, dann weiß ich morgen, was es eigentlich genau macht.
 
Zu synth: Bei mir verziehen sich meist die Augenbrauen wenn ich sehe, dass ein Kommandozeilenprogramm farbliche Ausgaben macht, vom eingebauten HTML-Generator ganz zu schweigen. Dass das Teil zum Bauen auch noch ADA braucht, macht es nicht gerade zu einer tollen Alternative zu portmaster.

Rob
 
Ich habe auch meine leichten Probleme mit synth, auch wenn mir die Vorteile einleuchten. Ein synth -upgrade-system dauert Ewigkeiten. Da mach ich lieber unregelmäßig einen komplett-Neubau mit portmaster -afD.
 
Zuletzt bearbeitet:
ports-mgmt/ports-tools haben FLAVOR Unterstützung bekommen:
https://www.freshports.org/ports-mgmt/ports-tools/

Hier wurden die ports-tools kurz vorgestellt:
https://lists.freebsd.org/pipermail/freebsd-ports/2017-May/108406.html

Und dort sind die ports-tools auf github:
https://github.com/ppekala/ports-tools

synth ist leider zu viel, braucht zu viel RAM und SWAP und viel zu viel Zeit, bislang ist synth nicht ein einziges mal sauber durch gelaufen, es konnte auch den gcc6-aux-20170802 nicht bauen, den es selbst braucht, während das alte portupgrade das Bauen erledigen konnte. synth hat aber auch Probleme mit dem installieren, es ist jedoch wohl schon eine neue Version unterwegs, aber zur Zeit noch nicht in den Ports:
https://forums.freebsd.org/threads/63525/page-2#post-367988

Zur Zeit empfiehlt sich auf der Baustelle wohl noch ein Helm, durch den Umbau auf FLAVOR. :ugly:
 
Na ja, wenn ich mir hier die Post's durchlese, entsteht doch der Eindruck, das synth experimentell und damit für den produktiven Einsatz eher nicht geeignet ist.
 
Was ist denn genau an poudriere "fett"? Es baut Pakete in einer Jail. Pakete bauen ist und Großen und Ganzen so oder so nötig und Jails sind ziemlich schlank. Poudriere ist in sh geschrieben und hat so gut wie gar keine Abhängigkeiten. Das System hat hinterher ein maßgeschneidertes PKG-Repo und das Basissystem/Jails sind nicht zugeklumpt mit irgendwelchen Build-Dependencies (GCC, zig Autotools Versionen, Doku-Generatoren, andere Compiler, CMake, ...)
 
Ich wollte schon lange mal mit poudriere rum spielen, dachte aber immer es wäre viel zu aufwendig die initiale Konfiguration etc. zu erstellen. Gestern Abend habe ich es dann einfach mal in einer VM ausprobiert und muss sagen, ich war echt überrascht wie schnell ich zu einem Ergebnis gekommen bin.

Ohne Buildzeit hab ich ca. 20-30 Minuten gebraucht und hatte am Ende ein kleines Repo für 10.3 und 11.1 erstellt.

@Fusselbär Fett würde ich poudriere nicht nennen, das was am meisten Speicherplatz verbraucht ist wohl der Portstree und den hat man doch eh, wenn man aus den Sourcen bauen will?
 
  • Like
Reaktionen: lme
Ich benutze Poudriere zum Testen meiner Ports (inkl. Abhängigkeiten) auf einem 9 Jahre alten Thinkpad X200. Da ist nix fett. Man brauch ZFS, aber das läuft seit Jahren einigemaßen ressourcenschonend. Man braucht Jails, aber theoretisch kann man hunderte Jails auf einer Büchse laufen lassen. Poudriere nimmt einen die ganze Erstellung von Jails und ZFS Datasets mit ein paar wenigen Kommandos ab. So schwer ist das nicht: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/book.html#ports-poudriere

Mit ccache zusammen dauert das Bauen der Ports meist auch nicht mehr so lange, da kann es sogar sein, dass es schneller baut als portmaster.

Und jetzt mal ehrlich: Wer hatte noch nie Probleme mit Portmaster hatte (Bau wird abgebrochen, man muss explizit Ports mit -x vom Bauen ausnehmen, installierte Pakete müssen manuell gelöscht werden, bevor es weiter geht)?

Wenn Poudriere etwas nicht bauen kann, dann ist der Port kaputt und es baut für niemanden.
 
Da ist nix fett. Man brauch ZFS, aber das läuft seit Jahren einigemaßen ressourcenschonend.
Ich benutze Poudriere mit UFS. Das funktioniert einwandfrei. Einziger Nachteil ist, dass es zu Anfang etwas länger dauert die Buildjails zu klonen. ZFS nicht zu mögen ist auf jeden Fall kein Argument gegen Poudriere.

Wenn Poudriere etwas nicht bauen kann, dann ist der Port kaputt und es baut für niemanden.
Erzähl das mal den ganzen Leuten die neue Ports oder Updates submitten aber es nicht für nötig halten die in Poudriere zu testen.
 
Zurück
Oben