1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

poudriere: Repo durch gewisse Optionen verschlanken

Dieses Thema im Forum "FreeBSD - Anwendungen und Ports" wurde erstellt von holgerw, 14 Mai 2017.

  1. holgerw

    holgerw Well-Known Member

    Registriert seit:
    29 Februar 2016
    Beiträge:
    1.185
    Ort:
    Simtshausen - Hessen
    Hallo,

    ich möchte demnächst mein plasma5 Repo samt einigen gängigen Desktop-Applikationen per Werbspace Neugierigen zur Verfügung stellen. Die Pakete sind signiert, geänderte Options in einer README dokumentiert u.s.f.

    Ich weiß, dass es bereits ein inoffizielles plasma5 Repo gibt. Das war bei mehrerem Antesten von mir aber immer dermaßen langsam, die Installation von xorg hätte schon Stunden gedauert, außerdem fehlen mir wichtige Applikationen wie libreoffice, claws-mail, audacity firefox und weitere,, dass ich mich entschlossen habe, mir per poudriere was eigenes zusammen zu bauen, woraus ich nach Basisinstallation ein komplettes plasma5 samt gängiger Desktop-Anwendungen installieren kann, ohne ständig zwischen verschiedenen Repos hin- und her zu switchen..

    Auf eine Anregung von @Athaba und einen Tipp von @Kamikaze hin bin ich nun doch neugierig, wie man durch einige Options in der make.conf zu einem schlankeren Repo gelangen kann.

    Mein neulich gebautes Repo hat stolze 3,1 GB, eigentlich wollte ich die 2 GB Marke nicht überschreiten.

    Wer Lust hat, hier repo-verschlankende make Options zu posten, möge das dann doch bitte mit knapper Erläuterung machen.

    Danke schonmal im Voraus und liebe Grüße,
    Holger
     
  2. holgerw

    holgerw Well-Known Member

    Registriert seit:
    29 Februar 2016
    Beiträge:
    1.185
    Ort:
    Simtshausen - Hessen
    Hallo,

    "[...]Vielleicht sollten wir da eine Wikiseite mit spannenden Options machen. sndio nutzen, libressl nutzen (TLS-SRP deaktivieren), habe auch GVFS weggekratzt (gab zuletzt mal ein paar Patches, die das möglich machen) was Zeit, aber vor allem auch sehr viel Kompilierzeit (und in weiterer Folge RAM und Disk Space) einspart.[...]"

    Das heißt also:
    + sndio
    + libressl
    - tls-srp
    - gvfs

    Ein Anfang, aber hat keiner hier weitere Ideen?

    Viele Grüße,
    Holger
     
  3. derOliver

    derOliver Systemheld

    Registriert seit:
    31 Dezember 2014
    Beiträge:
    373
    Ich halte davon gar nichts. Wenn man das so generell sagen könnte, dann wären die Port defaults wohl auch so gesetzt. Es ist aber immer eine Abwägung, was man haben will und was vielleicht mit etwas anderem kompatibel ist oder nicht.

    Konkret: es wird Programme geben, die mit LibreSSL nicht richtig funktionieren oder mit sndio. Anders herum wirds vielleicht Probleme und wenig getestete Seiteneffekte geben, wenn man auf gvfs verzichtet. Und dann wird es viele Programme geben, für die das alles kein Problem darstellt.

    Ein Beispiel:
    was passiert eigentlich wenn Programm A ALSA oder OSS verwendet und Progamm B sndio? Vielleicht geht's, vielleicht aber auch nicht. Ich habe keine Ahnung. Jedenfalls ist die Gefahr recht hoch, dass man da in wenig bis gar nicht getesteten Pfade läuft. Wer genug Verständnis vom System hat wird das herausbekommen und das Problem mehr oder weniger schnell lösen. Alle anderen stehen wie der sprichwörtliche Ochs vorm Berg.

    Du kannst natürlich gerne damit rumspielen und ein für dich passendes Set an OPTIONS finden. Bedenke aber immer, dass die für dich passen und wahrscheinlich für viele andere Leute nicht. Das bitte auch bei der Kommunikation mit anderen (vor allem Anfängern) bedenken. Da entstehen Probleme, die viele Leute nicht lösen können, nur weil man sich ein paar hundert MB auf der Platte spart.
     
    holgerw gefällt das.
  4. holgerw

    holgerw Well-Known Member

    Registriert seit:
    29 Februar 2016
    Beiträge:
    1.185
    Ort:
    Simtshausen - Hessen
    Oliver, diesen Einwand finde ich dermaßen überzeugend, dass ich lieber den Webspace vergrößere und es bei Defaults belasse - und die Verschlankungsexperimente nur mit einem Repo für meinem Rechner durchführe (dafür kann ich ja den Portstree zweimal unter jeweils anderem Namen importieren, und ich kann sauber trennen zwischen repo mit defaults und repo mit meinen Experimenten).

    Dennoch sind - nunmehr für mein eigenes Experimente-Repo - weitere Options zur Verschlankung willkommen. :D

    Viele Grüße,
    Holger
     
  5. Athaba

    Athaba Libellenliebhaber Mitarbeiter

    Registriert seit:
    10 März 2005
    Beiträge:
    3.311
    ,
    Der Hauptgrund warum bei Ports alles aktiviert ist ist, dass man in den offiziellen Paketen Funktionalitäten nicht hat. Deshalb wird meist möglichst viel was man wollen könnte nicht abdreht.

    Das ist quasi die Alternative zu dem was viele Linux-Distributionen machen mit jede Software in 50 Subpakete unterteilen oder eben dieses Optional Package Handling. Das hat FreeBSD nicht und braucht es wenn man von den Sourcen ausgeht auch nicht. Gerade für offizielle Pakete würde esaber Sinn machen.

    Ein Beispiel ist GVFS. Das ist großartig, wenn man es tatsächlich verwendet, und in Firefox oder Filmmanagern auf SAMBA, Google Drive und Co. zugreifen will. Will man das nicht hat man eine ganze Rendering Engine, ein ganzes Subsystem mit allen seinem Potential für Bugs, Ressourcenverschwendung, etc. dabei und wenn man selbst kompiliert dauert alles ewig, weil es kaum was größeres gibt als Compiler und Rendering Engines in den Ports.

    Auch will ich auf einen Server beispielsweise meist kein X, kein CUPS, kein SAMBA, etc.

    Ich stimme zu, dass man als kompletter Anfänger nichts tun sollte, womit man sich nicht auskennt und sich wie bei allem den Folgen bewusst sein muss.

    LibreSSL, welches du erwähnt hast ist ein schönes Beispiel. Das ist zwar mittlerweile echt gut und gerade wenn man sagt ich fahr meinen Mailserver und weiß dass ich da LibreSSL für OpenSMTPD habe (wird benötigt!), dann möchte ich, dass mir da OpenSSL nicht in die Quere kommt, also sag ich, dass LibreSSL einfach für alles verwendet wird und wenn's da nur um weit verbreitete Sachen geht geht das mittlerweile. Ansonsten rennt man in sowas, wie "mein pkg upgrade will OpenSMTPD deinstallieren".

    Zu den Seiteneffekten: JEIN. Das ist halt das "ich muss wissen, was ich damit mache" Problem. Das heißt bei LibreSSL einfach, dass ich wissen muss, dass das NICHT (mehr) OpenSSL ist. Wenn ich TLS_SRP brauche, dann kann ich nicht einfach so OpenSSL weg tun. Wenn ich ein Programm habe, das keinen OpenSSL-Support habe, dann wird das nicht funktionieren. Ist aber wie erwähnt mit Programmen wie OpenSMTPD genau das umgekehrte Problem. Dort würde ich also genau den Fall beheben.

    Und ja, ich würde es KEINESFALLS an "Ich tune mir da die 1%" raus nehmen. Wenn ich aber tatsächlich auf meinen Laptop die Hälfte der Pakete habe und ein Achtel der Kompiliert habe weil es GVFS und dessen Abhängigkeiten installiert, dann ist das ein sinnvoll genutztes Feature.

    Da rennt man in die Sache wie es in weiten Teilen der Gentoo-Community ist rein. Alle Compiler-Flags an, und irgendwelche Tunings aus einem Wiki kopiert, die ich nicht brauche.

    Aber es gibt viele Dinge, die man potentiell wirklich ändern will aus einem bestimmten Grund. GVFS habe ich schon erwähnt. Ich werde mit meinem Firefox hier niemals GVFS absichtlich verwenden, deshalb erspare ich mir das. Ich will auch anständig funktionierenden Sound haben und sobald mir PA in die Quere kommt, zerhaut es mir das (ja, auch in einem Default-Ubuntu) also stelle ich auf sndio um.

    Ich würde generell empfehlen solche Dinge nicht über einen Kamm zu scheren.

    Wenn ich ein sehr fundamentales Library ersetze, wie OpenSSL durch LibreSSL, mit einer Funktion, die auch vor allem dazu gemacht wurde andere Versionen zu verwenden, dann ist das so ziemlich der Extremfall. Wenn ich sage, ich will Feature X in nginx anschalten oder ich brauche auf meinem Router keine Docs, weil ich da jeden Megabyte haben will, dann ist das was anderes.

    Und der große Rest ist dazwischen. Aber da gilt die Regel, dass man einen Grund haben sollte das zu machen und sich über die Konsequenzen bewusst sein muss.


    Jetzt noch zur eigentlichen Frage. Ich habe das auf meinem Laptop so, dass ich darauf achte einheitliche Optionen zu haben, weshalb ich sie nicht per pkg setze. Das erspart mir unter anderem auch Inkompatibilitäten.

    Ich werde mal kurz über ein paar Sachen gehen und erklären warum ich das aktiviert oder deaktiviert habe.

    SNDIO aktiviert, PULSEAUDIO und PULSE, ALSA deaktiviert: Damit funktioniert mein Sound ohne Probleme in Firefox, VLC, Pulseaudio, wine, etc. Ich habe noch keine Anwendung entdeckt wo das Probleme macht und ich habe eine Weile XFCE so verwendet. Das ist aber relativ neu, dass das so gut geht. Da haben viele dran gemacht und ich sehe immer noch Commits in die Richtung, bei kleinerer Software.

    POSTGRESQL, PGSQL und RASTER aktiviert und pgsql=9.6 als Default Version. Das habe ich weil ich beruflich sehr viel mit Postgres und PostGIS arbeite. Ich verwende viele Features ziemlich zeitnah zum ersten Release und warte da meist schon Monate oder Jahre drauf, deshalb habe ich da immer die letzte Version. Ohne dem wäre mein PostGIS und diverse mit Support für eine ältere Version gebaut. Netter Seiteneffekt: Sollte ich andere Software haben die PostgreSQL unterstützt, wo es aber nicht aktiviert ist (ist ja doch potentiell eine große Abhängigkeit, wenn man es nicht nutzt), dann kann ich das gleich nutzen und muss nicht neu Optionen setzen und neu kompilieren.

    GVFS, SAMBA und GOOGLE deaktiviert. Damit werde ich GVFS los und damit sehr viele Dinge, wie unter anderem eine ganze Rendering Engine, die bei mir allein schon Stunden bauen würde. Da tut sich gerade viel, weil das viele loswerden wollen. GVFS nicht zu benötigen ist relativ neu, weil das bis vor kurzem nicht wirklich ging. Ist potentiell schon out of date.

    ssl=libressl-devel gesetzt, TLS_SRP deaktiviert. Hier ist es dehalb die libress-devel, weil bis vor kurzem nur die devel-Version mit mancher Software funktioniert hat. Ist jetzt eher redundant. Kann man auch auf das normale setzen, wenn man LibreSSL haben will oder muss. TLS_SRP sorgt dafür, dass Software, die SRP sonst braucht, das nicht aktiviert, weil LibreSSL das schon ziemlich früh über Bord geworfen hat.

    AESNI aktiviert: Damit werden in Paketen bestimmte Ports mit dem entsprechenden Assembly gebaut.

    UPNP deaktiviert: Weil ich zu paranoid dafür bin. Auf meinem Router zu Hause ist UPNP deaktiviert und ich will woanders keine Ports aufmachen. Das ist eine Sache die mich immer mal wieder gestört hat, weil ich UPNP wirklich nicht mag, nicht auf meinem Router unterstütze und auch wenn es von Software grundsätzlich ein optionales Feature ist, es teilweise aufgezwungen wird und beim ersten Start der Software, bevor ich in Optionen geht es einfach los läuft und dem Router sagt er soll Port-Forwarding machen.

    linux=c7 als Deault Version: Weil ich ab und zu mit Linux Binaries arbeite und da Sachen unter c6 nicht funktioniert haben.

    RUST_PORT=lang/rust-nightly: Weil ich mal eine Software kompiliert habe, die das Nightly Rust gebraucht hat.

    WINE_CROSS_BUILD=yes: Weil ich 32bit Windows Binaries ausführen will/muss.

    Das ist nur ein Auszug. Ich hab noch eine ganze Reihe von nginx-Sachen und Support für diverse Medienformate.

    Wie gesagt, ich versuche das generell zu haben und nur Sachen zu nutzen, die einen Grund haben.

    Ich kann derOlivers Argumente sehr gut nachvollziehen und es war ein Grund, warum ich Gentoo verlassen habe. Dort wurde das schlicht übertrieben und sowas färbt zu viel ab. Allerdings muss man halt auch schauen, was offiziell supported ist und was die Hintergründe sind. Die Defaults sind meist so, dass die meisten Leute damit leben können, was übersetzt heißt möglichst viel anzuschalten. Allerdings muss man auch sehen, dass der überwiegende Teil der Optionen offiziell unterstützte ./configure Optionen sind, wo in den Default-Settings unter FreeBSD mehr aktiviert ist als im offiziellen Paket, weil damit Leute die offiziellen Binary-Pakete nutzen können. Also wenn ich zum Beispiel einen Switch auch per default aktiviere, weil es könnte ja sein, dass jemand das Indexing in einer Desktopumgebung über eine Oracle DB haben will, dann ist das da aktiviert.

    Die Optionen sind Sane, aber was am meisten Sinn macht hängt halt stark vom Anwendungsfall ab und auch mit den ganzen Optionen da oben baut der größte Teil meiner Software mit den Defaults und das will man auch so haben, weil man sonst meist die falsche Software verwendet. Der Port-Entwickler weiß halt nicht ob es ein Router ist, ob ich GVFS ständig, manchmal oder niemals brauche.

    Der Grund warum ich oben das mit Gentoo erwähnt habe ist keinesfalls weil ich Gentoo hassen würde, sondern einfach weil ich es sehr gut finde, dass die Port-Entwickler diese Optionen anbieten, ohne da in Schwachsinn abzutrifften. Und das wirkt sich auch auf die Community aus. Ja, man könnte in der make.conf hunderte Compilerflags setzen, man könnte auch Patches haben um da zwei Cycles schneller sein in einem Programm und eine Option ranbauen und so weiter, aber das macht keiner. Und das ist der Teil wo auch eine Community und eine Philosophie dahinter stehen, die genau solchen Unsinn eben nicht macht.

    Das ist auch der Grund warum ich mich überhaupt traue diese Optionen auf meinem Produktiv-Laptop oder meinem Produktiv-Server zu setzen, wo es potentiell echt teuer werden würde, wenn mir das was zerschießen würde.

    Ich würde die Optionen also als Feature sehen, das man nutzen sollte wenn es Sinn macht. Genau so wie andere Dinge. Und was Sinn macht hängt vom Anwendungsfall ab. Und wie bei all den anderen Features, die FreeBSD oder auch andere Software hat macht es für gewöhnlich keinen Sinn jeden Switch, den switchen kann zu switchen. Auf keinen Fall alles tun, was man tun kann, und noch wichtiger: Wissen was man tut. Aber das ist hoffe ich ohnehin klar. Wenn ich FreeBSD installiere, darf ich nicht davon ausgehen, dass alles genau so läuft wie unter Windows. Und wenn ich mein OpenSSL durch LibreSSL änder (oder auch nur dessen Version ändere), dann wird das Auswirkungen haben. Es kommt eben auf den Anwendungsfall an. Auf einem Server, den ich betreibe verwende ich übrigens OpenSSL aus den Ports (weil ich da schnelle Elliptic Curves haben will), weil das dort für den Fall Sinn macht und ich bei dem System zu konservativ für LibreSSL bin.

    Ein großer Punkt bei Defaults zu bleiben, wenn man nicht andere Optionen haben will ist einfach auch die Tatsache dass damit die meisten Systeme laufen, also am Besten getestet wurde. Deshalb auch wenn es oft genug wirklich Sinn macht was abzuändern (sonst würde sich wohl kaum jemand die Mühe machen), nicht einfach auf gut Düngen oder gar nach Gefühl gehen. Aber wie erwähnt. Das trifft auf alle Bereiche zu und ich hoffe, dass jemand der oder die daran denkt da was abzuändern da zumindest ein grundsätzliches Bewusstsein hat.

    Und zum Thema Deaktivieren/schlanker: Der aller größte Teil ist es meines Erachtens nicht wert da Zeit zu investieren. Nicht alles zieht solche Unmengen/Ungetüme an Dependencies, wie GVFS und oftmals kann es sogar nett sein das zu haben, oder wenn man eine DE fährt hat man die meisten sowieso durch andere Pakete, die das dann unbedingt benötigen. Und ich habe auch kaum mit Dingen ein Problem wie mit UPNP. Die meisten Dinge, die ich deaktiviere sind Optionen die "Choose exactly one" sind und wo ich einfach was anderes haben muss, damit es das tut was ich will. Sowas, wie Postgres statt MySQL. Oder eben so extrem optionale Dinge, wie SAMBA. Ich habe einfach kein SAMBA. Der Code kann gar nicht auf eine Art verwendet werden die zu irgendeinem Ziel führen würde, was wieder ähnlich wie MySQL-Support ist.

    Was ich auch nicht tun würde ist zum Beispiel auf Ports umsteigen, weil ich GVFS loswerden will. Die Pakete sind zwar teilweise groß, aber wenn ich sie ohnehin nicht selbst für wirklich Stunden parallelisiert kompiliere, dann soll es nicht meine Sorge sein.

    Okay, das war jetzt ein langer Post, aber ich will nicht, dass da jemand glaubt ich mache um irgendwo ein paar Bytes "wegzutunen" oder das gar als Ratschlag sieht Optionen ist, weil es irgendwie per se besser wäre. Wenn Pulseaudio funktioniert, warum ändern? Wenn GVFS verwendet wird (kann ja wirklich nützlich sein!), warum deaktivieren? Wenn OpenSSL passt und das eben derzeit der Default ist und man nicht testen will, bzw. das nicht das größte Thema ist, warum ändern? Wenn man UPNP auch sonst verwendet, warum das dann nicht gleich dabei haben? Wenn man mit seinem Postgres glücklich und zu frieden ist, warum was neues, weniger getestetes nutzen? Würde ich nie machen, wenn es mir nichts bringt!

    Also bitte, bitte davor überlegen, was Sinn macht. Ansonsten versuchen Entwickler, die meist viel mehr als man selbst darüber nachgedacht haben es für gewöhnlich besser. :)

    Und zuguterletzt noch was zu der Anregung, die vielleicht etwas falsch verstanden wurde: Mir ging es vor allem darum ein Bisschen Wissen um die Optionen zu häufen. Ein Beispiel. SNDIO aktivieren ist schön und gut, aber wenn ich nicht die zwei(!) Optionen für Pulseaudio deaktiviere wird es nicht gehen. Außerdem arbeiten da Entwickler dran, dass das geht. Ich glaube man kann in der Community Probleme schneller erkennen. Und manchmal gibt es halt caveats, wie bei LibreSSL. Das steht dann im FreeBSD Wiki irgendwo, vergraben im Projekt, und ja vielleicht sollte man da reinschauen, aber gerade wenn man neu ist weiß man nicht wie das dann genau ist. Oft machen außerdem "Sets" von Konfiguration Sinn. Leider ist sowas schwierig abzubilden, ohne das Leute dann glauben, sie sollen das machen weil das System einfach zu dumm ist und man das als Nachbessern sehen muss. Ich glaube wenn es Doku gibt und das auch als Teil davon klar macht, dann ist das sinnvoller als kurz in einem Thread wo es Probleme macht reinzutun. Weil wenn man mal so nett ist und einem Neuling ein Snippet schickt, dass ein Paket so ändert, dass irgendwas wie gewünscht funktioniert und jemand anders googlet danach, findet den Post, hat ein Problem dass sich oberflächlich ähnlich anhört, aber zerschießt dann das System, weil es eben doch ein anderes Problem ist, dann denke ich macht zum Beispiel ein Wiki-Artikel mit ausführlicher Erklärung wesentlich mehr Sinn.

    Das ist ähnlich wie bei sysctls. Es gibt einen Unterschied zwischen welchen die man setzt damit es funktioniert oder nicht (IP forwarding), welche die nett und harmlos sind (autoboot delay auf 5 statt 10 Sekunden), Sachen wo man sich über Konsequenzen bewusst sein muss (securelevel, user mounts, etc.), Tuning das manchmal sehr nötig ist und manchmal komplett unnötig (ich brauche meinen Laptop nicht so konfigurieren dass 10GBit deutlich schneller verarbeitet werden oder kern.maxfiles Werte auf Router, Desktop, Server, etc.), und in den meisten Fällen sind die Defaults ohnehin am Besten und autotuned.

    Schönen Abend noch! :)
     
    holgerw gefällt das.
  6. derOliver

    derOliver Systemheld

    Registriert seit:
    31 Dezember 2014
    Beiträge:
    373
    Das sind alles valide Punkte, nur nicht für ein öffentliches Repo, dass auch andere verwenden.

    Danke aber für deinen Input, ich denke das hilft dem Holger ein ganzes Stück weiter.
     
    holgerw und Athaba gefällt das.
  7. holgerw

    holgerw Well-Known Member

    Registriert seit:
    29 Februar 2016
    Beiträge:
    1.185
    Ort:
    Simtshausen - Hessen
    Hallo @Athaba

    was für ein Kommentar mit so vielen Hinweisen samt ausführlicher Erläuterung .... vielen vielen Dank. :)

    Einiges (vor allem sndio, gvfs) werde ich gleich beim plasma5 repo ausprobieren. Für ein spezielles Gnome3 Repo etwa dürfte es hingegen keine gute Idee sein, gvfs weg zu lassen (Achtung, ist bloß eine Vermutung von mir).

    Oliver, ich finde Deinen Einwand nach wie vor richtig, ich denke, ich kann aber guten Gwissens ohne die Optionen gvfs und sndio (plus den pulse-Kram) auch mein inoffizielles Repo zur Verfügung stellen, weil:
    - das noch ziemlich überschaubar ist
    - ich sämtliche Modifikationen in einer README und Neubauten in einer NEWS Datei erläutern werde
    - ich darauf hinweise, dass dies inoffiziell und vor allem auf meine persönlichen Anforderungen ausgerichtet ist, und daher auf eigenes Risiko zu verwenden ist

    Davon abgesehen ist es selbstverständlich für mich, darauf hinzuweisen, dass sämtliche Fragen zu diesem inoffiziellen Repo nicht in die offiziellen Bereiche von bsdforen.de oder gar den forums.freebsd.org gehören, sondern allenfalls die eine oder andere Sache im Bereich Geplauder abgeklärt werden kann.

    Nun muss ich allerdings erstmal schauen, wie ich wieder an die Sourcen zu plasma5 komme.

    http://area51.pcbsd.org/ ist nach wie vor nicht erreichbar, und https://src.mouf.net/area51/browse/branches/plasma5 lässt sich mit svn nicht auschecken :ugly:

    Viele Grüße,
    Holger
     
    Zuletzt bearbeitet: 21 Mai 2017
  8. ralli

    ralli Well-Known Member

    Registriert seit:
    1 Juni 2012
    Beiträge:
    1.771
    Da stellt sich natürlich auch die Frage, warum das nicht mehr erreichbar ist. Die Möglichkeit, das es bewußt nicht mehr erreichbar sein soll, ist ja nicht weit hergeholt und daher auch nicht gänzlich auszuschließen. Dann nämlich und das ist doch sehr wahrscheinlich, werden schwerwiegende Gründe dafür vorliegen, die eben zu dieser Entscheidung geführt haben. Ob das noch mit Serverarbeiten erklärt werden kann, zweifel ich zusehends an.
     
  9. holgerw

    holgerw Well-Known Member

    Registriert seit:
    29 Februar 2016
    Beiträge:
    1.185
    Ort:
    Simtshausen - Hessen
    Hmm, mich wundert, dass auf https://freebsd.kde.org dazu gar nix kommuniziert wird.

    Vielleicht ist Tobias - wie @lme - auch im Urlaub :)