Re: von FreeBSD 10 auf 11 - ALLE Ports neu bauen?

On Sat, 28 Jan 2017 13:55:43 +0100, O. Hartmann wrote:
> Am Sat, 28 Jan 2017 12:30:18 +0100
> Heino Tiedemann <rotkaps_spam_trap(at)GMX.de> schrieb:
>
> > Polytropon <freebsd(at)edvax.de> wrote:
> >
> > > On Fri, 27 Jan 2017 23:29:44 +0100, Heino Tiedemann wrote:
> > >> Ich habe Montag angefangen mit dem Update von 10.2 auf 10.3 und bin
> > >> JETZT (Freitag) endlich fertig alle Ports zu updaten.
> > >
> > > Von 10.2 auf 10.3 sollte das nicht nötig sein (obwohl es
> > > auch grundsätzlich nicht schadet), aber wenn Du auf 11.0
> > > aktualisierst, wäre es schon sehr empfehlenswert.
> >
> > Missverstanden: Nur die Ports, die fällig waren - aber das waren
> > viele!
>
> In vielen Fällen lauert noch ein weiteres Problem: zwar laufen Ports partiell, aber nach
> meiner letzten Erfahrung, das war ein Wechsel von 10.3 auf 11 auf einem
> Überwachungsserver, gabs immer wieder ABI Probleme, die in mysteriösen Abbrüchen von
> Programmen führten.

Und _das_ sollte eigentlich nicht sein, da der Ports-Baum
im Grunde ja sagt: "läuft auf Version 11". Aber der Build-
Server, der die Pakete vorcompiliert, macht eben nur das:
er übersetzt - er testet nicht ("runtime").

> > Gerade wenn die installierten Ports nicht laufen, dann habe ich kein X
> > kein XFce, keinen Firefox, Keinen Emacs/Gnus, keinen Clementine-Player...
> >
> > .. final also einen unbrauchbaren PC für mehrere Tage, wenns hoch kommt.
> >
> > Sehr ärgerlich, wenn man was zum bauen startet, nach der Arbeit nach
> > hause kommt und merkt: Abgebrochen. Das wirft einen wieder einen Tag
> > nach Hinten.
>
> Ja, das geht mir ähnlich. Vor allem auf etwas "schwächeren" Maschinen, ich habe einen
> älteren Zweikern-IvyBridge, bricht Libreoffice sehr oft ab, nicht zu vergessen die
> Schwergewichte gtk2/gtk3/qt5 und webkits. Libreoffice baut rund drei Stunden. Ein Abbruch
> bedeutet: alles neu. Müsig.

Richtig. Das "Fortsetzen" eines abgebrochenen Paketbaus ist
in den meisten Fällen nicht möglich (oder nicht, ohne sich
dabei neue Probleme anzulachen)...

> > > Der Vorteil, wenn man nur mit Binärpaketen arbeiten kann,
> > > liegt hier klar auf der Hand, da macht pkg alles neu,
> > > auch sich selbst (ggf. die "pkg-static-Falle").
>
> "Arbeitet" man mit Binärpaketen, ist amn darauf angewiesen, daß der Host, der die
> Binärpakete vorhält, immer erreichbar ist und die Pakete so konfiguriert, wie man sie
> selber braucht. In einer heimischen Frikkelumgebung mag das noch alles problemlos gehen,
> wird FreeBSD aber, ausnahmsweise, mal in einer komplexeren Umgebung eingesetzt, läuft
> man mit den "Kompromißlösungen" aus den Standardrepositorien ganz schnell gegen die
> Wand! Das beginnt bei SASL Unterstützungen diverser Pakete (OpenLDAP), die Verwendung
> neuer Datenbanken (PostgreSQL 9.6 statt 9.5) und SAMBA 4.4, nur um ein paar der schweren
> Gewichte zu nennen. Der Apache 2.4 und Multithreading ist ebenso ein solcher Kandidat.
> FreeBSD hat ernste Probleme auf dem terrain, wo eigentlich die Domäne des Systems liegen
> sollte, nämlich im Serversektor, wenn man Binärpakete einsetzt.

Das kann ich völlig nachvollziehen. Im Heimbereich stelle
ich solche "Spezialfälle" kaum fest, da kommt man mit den
normalen Binärpaketen sehr bequem durchs Leben, aber auf
Servern, wo die Default-Optionen oftmals nicht das sind,
was man braucht, helfen Binärpakete nicht direkt weiter.
Angenehm ist hier eine "poudriere"-Umgebung. Für Klein.
kram geht auch "pkg lock" und "pkg unlock", aber das fühlt
sich wieder wie Bastelstunde an. :-)

> Das größte Übel ist: hat man EINEN Port manuell mit seinen Optionen gebaut und ist der
> Baum neuer als der Paketbaum eines entfernten Servers, will pkg sehr oft aufgrund seiner
> Konsistenzprüfung eben andere pakete nachinstallieren, meist "Downgrade". Und dann
> beginnt ein echter Kampf.

Und besonders "schön" wird das, wenn man (aus welchen Gründen
auch immer) eine "nicht ganz aktuelle" Version von etwas
nutzen muß... :-)

> > Ich muss zugeben ich habe mich nie groß mit Binärpaketen
> > auseinandergesetzt.
>
> Ich auch nicht, siehe oben. Es frißt mehr Arbeit, als daß es einem Arbeit erspart.

Sehe ich nicht so, zumindest nicht im Heimbereich. Aber das
ist auch wirklich nur meine ganz persönliche Einstellung und
Erfahrung, nicht zwangsläufig auf alles und jeden übertragbar.

Kerngedanke: Wenn die Voreinstellungen der Ports passen, dann
ruhig alles mit pkg installieren und updaten.

> Wir (und ich auch) setzen zunehmend JAILS auf diversen Hosts zur trennung von Diensten
> ein. Hinzu kommt, daß ich einige "Eigenbaurouter" habe, die auf der Basis der PCengine
> APU 2C4 aufbauen und als TK Anlage, Router und Firewall arbeiten. Aus Sicherheitsgründen
> können und dürfen diese Systeme nicht mit der Außenwelt in Verbindung treten und hier
> sind auch speziell konfigurierte und gepatchte Ports im Einsatz. Und hier tritt dann
> wieder einer der Vorteile des FreeBSD Systems in den Vordergrund: poudriere!
>
> Anfangs ist die Lernkurve sehr steil - man muß etwas Zeit und Geduld aufbringen, um das
> System zu konfigurieren und vor allem: auf die eigenen bedürfnisse anpassen. Dann aber
> kann man einfach seine benötigten Ports konfigurieren und bauen lassen. Über Nacht, auch
> mit Abbrüchen und späterer Fortsetzung! Das Resultat ist ein eigenes
> Binärpaket-Repositorium. Es kann lokal im Dateisystem abgelegt und auch lokal von pkg
> angesprochen werden oder man geht den "Männerweg" ;-) und baut sich einen Webserver, der
> im LAN erreichbar die Pakete anbietet. Wir haben Ports für CURRENT und 11. Ich schimpfe
> zwar oft über FBSD, weil es doch einigen Murks gibt, aber diese Autarkie, die wir mit
> unseren Paketen haben, ist mit anderen Systemen nur schwer erreichbar!
>
> Vor allem aber kann man mit poudriere die Auszeiten und den Frust, falls ein Port defekt
> ist und nicht gebaut werden kann, lindern. Solange poudriere Ports nicht bauen kann,
> wird das intakte Repositorium, das man tunlichst "woanders" hostet (wir synchronisieren
> die Buildfolder mit rsync nach Erfolg auf eine andere Partition, die via NFS eingebunden
> ist - beispielsweise), nicht zerstört. Erst wenn der komplette Bauprozeß erfolgreich
> abgeschlossen wurde, synchronisiert man. und es ist einfach "scharf" zu sehen, wie
> schnell Binärpakete, die man exakt mit allen Optimierungen für die Platform (CPU,
> Anpassungen, Patches) über ein 1GBit oder 10GBit LAN auf die zu erneuernden Systeme
> fließen.

Das ist eine schöne Charakterisierung von poudriere. Nein, im
Ernst: Es ist ein sehr praktisches Werkzeug, das, wenn man sich
erstmal die Mühe gemacht hat, seinen Gebrauch zu erlernen und
zu üben, die Arbeit fast von allein macht, also genau wie jedes
gute Werkzeug. Alles, was man über Handwerkzeuge sagen kann,
gilt auch für dieses "digitale Tool".

Ich möchte "trotzdem" noch eine Lanze für pkg brechen: Für den
Heimgebrauch, nach _meiner_ Erfahrung, leistet es gute Dienste,
man muß sich nicht mit "störrischen Ports" rumschlagen. Und das
ist zumindest einen Versuch wert.

Im Grunde kann man Parallelen zu quellcode-basierten Systemupdates
und der Verwendung von freebsd-update ziehen: In vielen Fällen ist
freebsd-update sehr bequem und praktisch, aber wenn man nicht mit
GENERIC arbeiten kann (z. B. bestimmte Kernel-Optionen braucht)
oder src.conf modifizieren muß, muß man mit "make buildworld" etc.
arbeiten. Das ist nicht jedermanns Sache, klar, aber wenn man
diesen "Werkzeugkasten" erstmal begriffen hat, ist er ungeheuer
praktisch, komfortabel, effizient und angenehm. Genau so ist es
auch mit pkg, den klassischen "make install"-Ports (bzw. Tools
wie portmaster) und poudriere.

-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message