Vorteile von Poudriere über Synth?

S

SolarCatcher

Well-Known Member
Hallo,

bis vor kurzem habe ich die wenigen Ports, die ich noch selbst kompiliere, per portmaster hergestellt. Reichte für mich eigentlich immer aus. Seit ich meinen Laptop nun endlich ins ZFS-Zeitalter gebracht habe, nehme ich allerdings ports-mgmt/synth, weil es einfacher zu handhaben sein soll, als Poudriere, mit dem ich noch keine Erfahrung habe.

Nun lese ich hier - z.B. in diesem Destktop-Thread - immer wieder den Tipp, Poudriere zu nutzen. Mich würde interessieren, ob das geschieht, weil es tatsächlich interessante Vorteile gegenüber synth bietet oder weil es einfach die eingeführtere/bekanntere Lösung ist?

Wer Synth noch nicht kennt: Auf Github findet man die wichtigsten Infos dazu https://github.com/jrmarino/synth

Und hier ein längeres Interview mit dem Synth-Entwickler im BSD Now Podcast
 
Ich habe von Synth noch nie gehört aber das liest sich für mich als würde es sich zwischen die poudriere und portmaster Stühle setzen.
 
Beide build systeme haben ihre vor und Nachteile.

bei poudriere erstellt man eine golden master jail, unter ZFS wird diese dann mittels snapshots sauber gehalten was sehr schnell geht, unter UFS habe ich es lange nicht mehr getestet kann daher nicht sagen ob die build umgebung noch mittels cpdup erstellt wird (fuer jeden port, da war tinderbox beim erstellen der build Umgebung auf UFS schneller)

synth arbeitet mit (ro) nullfs mounts und kann dafuer das basis OS verwenden, dies kann aber auch nach hinten losgehen wenn das basis OS nicht clean ist (reste vom vorgaenger, kein make delete-old ...).
Wie bei poudriere gibt es aber bei synth die moeglichkeit eine referenz jail fuer die builds zu nehmen (dann spart man sich das suchen warum falsche libs z.b. ssl, crypto, usw. angezogen werden)

Beide systeme berherschen cross build, d.h. auf einem 11-amd64 koennen mittels 10-i386 jail ports gebaut werden.
poudriere laesst sich sehr leicht scripten und damit z.B. mittles jenkins und/oder hooks triggern, behersscht mehrere ports trees und "package sets" (interresant fuer prod und dev), scripten sollte bei synth aber auch gehen wenn "Display_with_ncurses= false" fuer den build gesetzt ist.

Der grosse vorteil von beiden systemen ist das man eigene (saubere) update repos baut, das system wird erst mittles "pkg upgrade" aktualisiert wenn alle ports fertig sind, synth bietet dies per default an, pouderie nicht da das ziel nicht ein single host ist/war.

Mein pers. tipp, wenn die zeit es zulasst beide systeme testen und sich fuer das entscheiden mit dem man besser zurecht kommt (synth aber nach ersten tests bitte auch nur mit einem golden master jail verwenden).
 
@socke Das mit der "Golden Master" Jail für Synth klingt nach einer guten Idee.

Mein Problem mit Synth: Ich hatte nach kurzen Erfolgen schon bald Probleme, weil die installierten Packages nicht 100% exakt mit der Version in den Ports übereinstimmten (auch wenn es nur Tage waren). Es gibt bestimmt einen einfachen Weg, wie man den lokalen Portstree auf genau die SVN-Revision bringen kann, die auch das letzte Built der offiziellen FreeBSD-Repos genutzt hat. Leider kenne ich den nicht...
 
Wenn ich das richtig verstanden habe willst du nur eine auswahl an ports bauen bauen und den rest per packages installieren?
Wie wird denn /usr/ports aktuell gehalten per SVN oder portsnap (wenn per SVN, von ports/head oder ports/branches/201nQ[1-4])?
Die SVN rev. aus denen die ports gebaut werden kann man auf den buildservern rausbekommen, leider ist die SVN rev. nicht auf dem pkg server abrufbar, wurde in deinem fall etwas zeit sparen.
Schildere mal kurz wie dein setup bisher ist, also von wo die meissten packages installiert werden, plus die OS rev, und arch.
 
Die wenigen Fälle, wo ich etwas selbst baue sind z.B. graphics/mozjpeg (Installation in einen speziellen Ordner, der sich nicht mit den sonstigen JPEG-Tools beißt) oder bis kürzlich emulators/virtualbox-ose-kmod (um MS Office unter Win laufen zu lassen). Und auf dem Server habe ich neulich security/letsencrypt.sh selbst "gebaut", weil ich zsh statt bash verwenden wollte.

Mit Portmaster habe ich - solange es ging - immer die "-P" Option verwendet (installier Dependencies wenn möglich aus Paketen; und nur wenn das nicht geht, baue sie selbst) und später diese Funktionalität von Hand nachgestellt (portmaster laufen lassen, sehen, welche Dependencies benötigt werden, diese als Pakete installieren, dann portmaster jeweils mit "-x" und den Namen der Dependencies). Letztlich wollte ich meist nur ein Paket wirklich bauen und installieren.

Durch Synth/Poudrière kann man jetzt ja auch noch auf die Installation von Build-Dependencies verzichten (im eigentlichen live System). Soviel zu meinem ganz bescheidenen Use-Case.

Ich habe Synth mit "fetch prebuilt packages TRUE" konfiguriert und erreiche damit sehr genau, was ich will. Es gibt eben nur Probleme, wenn die Pakete mitunter auch nur minimalst von der Version des lokalen Portstrees abweichen. Ich nutze die offiziellen FreeBSD-Repos mit den aktuellen (nicht den vierteljährlichen) Paketen. Wenn ich wüsste, wo man die SVN-Revision dieser Builts einsehen kann... könnte ich /usr/ports natürlich genau auf jenen Stand bringen. Ich würde ja sogar tippen, dass jemand bereits ein Skript für genau diese Aufgabe entwickelt hat...
 
Das Problem mit den aktuellen abweichenden ports sollte zu loesen sein wenn quarterly anstatt head ausgecheckt wird.

Hier liegt evtl. auch der Knackpunkt, portsnap liefert head, quaterly geht nur per SVN oder evtl. auch per git und beim wechsel von Q1->Q2->Q3->Q4 aendert sich der pfad im SVN repo.

Bei einem Mix aus fertigen Paketen und Selbstbau mit "head" gibt es wie schon bemerkt wurde zu schnell zu viele Aenderungen, quarterly bekommt aber meist nur sec. und build fixes.

Code: 
# mittels svn/svnlite kann der aktuelle quarterly tree wie folgt ausgecheckt werden
# (svnlite is bereits im basis OS enthalten)
$ cd /usr/
$ mv ports ports.head
$ svnlite co http://svn.freebsd.org/ports/branches/2016Q2 ports

# bei einem Wechsel auf branches/2016Q3 (Anfang Juli)
$ cd /usr/ports
$ svnlite switch ^/branches/2016Q3

# ports aktualisieren:
$ svnlite update

Um das ganze kurz zu testen (mur ein port wird nach /tmp ausgecheckt und der Qx branch gewechselt)
Code: 
$ cd /tmp
$ svnlite co --depth empty http://svn.freebsd.org/ports/branches/2016Q1 ports_demo
$ cd ports_demo
$ svnlite up --set-depth empty graphics
$ svnlite up graphics/mozjpeg

# wechsel auf 2016Q2
$ cd /tmp/ports_demo
$ svnlite switch ^/branches/2016Q2

Die aktuelle svn rev. die zum Bau der Pakete auf dem FreeBSD cluster verwendet wurde sollte somit nicht mehr so stark abweichen.
Ein regelmaesiges "svn cleanup" hilft nach "svn switch" das .svn Verzeichnis aufzuraeumen
 
Hallo socke, das genau wollte ich ja nicht machen - auf die quarterly Packages wechseln. Aber soweit ich mal gehört habe, werden auch die ca. wöchentlichen Builts so erstellt, dass sie - selbst wenn sie auf verschiedenen Maschinen über längere Zeit gebaut werden, auf einer Version des Portstrees basieren. Ich weiß nur nicht, wo man diese Revisionsnummer herbkommt, um dann seinen lokalen Portstree darauf einzustellen.
 
die Pakete werden momentan auf einem der beefy[1-n].isc.freebsd.org/ gebaut, auf dem 1'er rennt z.B. gerade ein 93i386-default build.
Wenn du die richtige beefy kiste zu deiner OS rev. findest und auf den letzten build gehst findest du z.B. folgende infos, hier fuer den 101i386-quarterly
Code: 
Master     101i386-quarterly
Build     417177
Status     stopped:done:
Jail     101i386
Set
Ports Tree   quarterly
SVN     svn://svn0.us-west.freebsd.org/ports/branches/2016Q2@417177
Die zeile SVN gibt aufschluss ueber den svn zweig (head oder branch) der wert nach dem @ die SVN revision
 
Ich hab den Vorteil von poudriere noch nicht ganz erfasst.. Kann ich damit auf meinem Macbook unter virtual box (freebsd amd64) dann Pakete für mein krüppeliges atom-netbook (i386, march?=native) bauen? Chrome update dauert dort gute zwei Tage :ugly:
 
Esjott schrieb:
Ich hab den Vorteil von poudriere noch nicht ganz erfasst.. Kann ich damit auf meinem Macbook unter virtual box (freebsd amd64) dann Pakete für mein krüppeliges atom-netbook (i386, march?=native) bauen? Chrome update dauert dort gute zwei Tage :ugly:
Zum Vergrößern anklicken....
Der Hauptverwendungszweck von Poudriere und Synth ist es, Pakete zu bauen, ohne dabei das eigentliche System mit lauter Build-Abhängigkeiten etc. "zu verschmutzen". Beide Tools bauen separat vom eigentlich laufenden OS ein Repository for neu-gebaute Pakete auf - also auch mit Deinen persönlichen Configs. Aus diesem kannst Du dann ganz gewohnt über pkg die Pakete installieren. Cross-Builds sind ein Spezialfall und dafür natürlich extrem vorteilhaft.
 
Esjott schrieb:
Ich hab den Vorteil von poudriere noch nicht ganz erfasst.. Kann ich damit auf meinem Macbook unter virtual box (freebsd amd64) dann Pakete für mein krüppeliges atom-netbook (i386, march?=native) bauen? Chrome update dauert dort gute zwei Tage :ugly:
Zum Vergrößern anklicken....
Ja das sollte gehen, suche einfach mal nach "freebsd poudriere cross build arm packages" allerdings kann PD nicht wie synth bereits fertige pakete von pkg.freebsd.org ziehen hier wuerde alles von Anfang an gebaut werden. Ob synth cross build kann, kann ich wegen mangelnder Erfahrung mit synth nicht sagen, eine mail an freebsd-ports (evtl. CC marino@) sollte dies aber schnell beantworten.

@SolarCatcher
Habe mal eine ticket fuer PD aufgemacht, mit request die ports tree SVN rev. zu tracken und nach dem build zu publishen mal sehen was daraus wird.
https://github.com/freebsd/poudriere/issues/398
 
Danke SolarCatcher und socke, habe mich etwas eingelesen und mein nächstes Projekt in Angriff genommen :D Ein erster quick'n'dirty Aufsatz in der VirtualBox unter MacOS war erfolgreich, jetzt kommt das ganze in hübsch und damit /usr/ports von den Platten (auf dem Homeserver und dem Netbook), Qemu braucht es für den DN2800 und N450 nicht.

Wie gesagt, danke!
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben