# chromium wieso kein Binärpaket?

## ChrisJumper

Seit dem Chromium von 3,5 Stunden Buildtime auf 5 Stunden 20 Minuten gewachsen ist verspüre ich so ein leichte Abneigung gegen den Browser. Kann man da nix machen?

Würde ein Git-Respository und das ein Make, eventuell nur die geänderten Code-Stellen neu baut zumindest die Compiler-Zeit etwas drücken?

Kann ich ein Binärpaket mit fest statischen Libs bauen das auf allen amd64 Systemen läuft bauen? Selbst wenn es etwas mehr Zeit in Anspruch nimmt wäre es mir auch noch lieber als es auf den verschiedenen Systemen immer wieder zu aktivieren. Kann auch sein das der Anstieg an der SSD, den KAISER-Patches und den neuen Compiler liegt.

Vielleicht machen sie es wie Mozilla und blähen alles unnötig auf.

Besonders ärgerlich war halt der Release der neuen Version, einen Tag nachdem ich erst aktualisiert hatte. Die gefixte Chrome-Lücke las sich jetzt auch so das ich den Browser ohne Update nicht mehr verwenden wollte.

Würde man bei Gentoo nicht auch Zeit beim Compilieren sparen, wenn man den geänderten Code vorher zur vorherigen Version vergleicht und nur sich geänderte Teile neu compilieren muss? Ccache war ja so ein Ansatz aber eher dafür wenn man mehrmals ein und das selbe Paket neu kompiliert. Vielleicht ist es aber auch zu Fehleranfällig bzw einfach der Diff bei der großen Dateimenge zu groß und man baut deswegen wahrscheinlich alles neu oder?

Irgendwo hab ich da bestimmt einen Denkfehler und ich muss da noch mal drüber genauer nach denken.

----------

## franzf

ccache sollte evtl. etwas helfen. Das Problem ist nur, dass mit einem irgendeinem geänderten header (auch aus externen Abängigkeiten) eine C- oder C++-Datei neu kompiliert werden muss, selbst wenn sie selbst sich nicht geändert hat. Dabei reicht es, wenn sich im header der Copyright-header, ein Dokumentations-Kommentar oder etwas anderes nicht den Code betreffendes ändert. Meine Erfahrung mit CCache ist leider auch die, dass es speziell bei häufig aktualisierten Systemen mit vielen ~arch-Paketen nicht mehr so effektiv funktioniert und man oft nur den zusätzlichen Ballast (compile cache auf der Platte) mitschleppt.

Betreffend Binärpaket: Da gibt es www-client/google-chrome. Das ist wie bei firefox-bin das offizielle Binärpaket. Für libreoffice machen sich die Gentoo-Devs die Mühe, eigene Binärpakete zu erstellen. Du kannst ja mal vorsichtig auf bugs.gentoo.org nachfragen, ob sich jemand die Mühe machen will, auch ein chromium-bin für Gentoo zu pflegen...

EDIT: Es gibt im betagarden-overlay ein chromium-bin-debian: https://gitweb.gentoo.org/proj/betagarden.git/tree/www-client/chromium-bin-debian

Das ist aber leider immer noch ein 63er chromium (kenn mich mit den chromium-releases nicht aus, kann also sein dass das eine Version ist, die nicht von den aktuellsten Lücken betroffen ist...)

In debian jedenfalls gibt es neben dem 63er auch den neuesten 64er: https://packages.debian.org/de/chromium

----------

## Tyler_Durden

 *ChrisJumper wrote:*   

> Irgendwo hab ich da bestimmt einen Denkfehler und ich muss da noch mal drüber genauer nach denken.

 

Bestimmt, denn wenn Du chromium als Binärpaket möchtest, dann ist es halt google-chrome. Gibt's als stable, beta und unstable.

----------

## ChrisJumper

```
Sun Feb 11 12:34.56 2018 >>> www-client/chromium-64.0.3282.140

       merge time: 5 hours, 18 minutes and 9 seconds.

     Tue Feb 20 12:34:56 2018 >>> www-client/chromium-64.0.3282.167

       merge time: 9 hours, 14 minutes and 39 seconds.
```

Verwendet hatte ich:

```
EXTRA_GN="use_jumbo_build=true" emerge -av chromium
```

Die Useflags:

```
cups hangouts jumbo-build pic proprietary-codecs pulseaudio suid system-ffmpeg
```

Aber ich denke das Problem warum es länger gedauert hat, war das ich halt tempfs nicht im RAM hab und 8 GB Swap auf einer langsamen 7200upm Festplatte.

```
# gcc -v

Es werden eingebaute Spezifikationen verwendet.

COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/7.3.0/gcc

COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/lto-wrapper

Ziel: x86_64-pc-linux-gnu

Konfiguriert mit: /var/tmp/portage/sys-devel/gcc-7.3.0/work/gcc-7.3.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/7.3.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 7.3.0 p1.0' --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx --enable-vtable-verify --enable-libvtv --enable-lto --without-isl --enable-libsanitizer --enable-default-pie --enable-default-ssp

Thread-Modell: posix

gcc-Version 7.3.0 (Gentoo 7.3.0 p1.0)
```

Kernel ist ein 4.15.2 und cpu war Intel mit vier Kernen und 3.10GHz.

----------

## LuxJux

So ein Ähnliches Problem hab ich auch grad.

Der Prozessor (i5@3.4,Quad) läuft bei 100%

Meine SATA schreibt mit ( irgendwas mit KB)

Die könnte aber 60 MB/sekunde

Da scheints wohl noch wo anders dran zu haken.

Oder kann die Festplatte nicht voll arbeiten, wenn der Prozessor ausgelastet ist ?

----------

## LuxJux

Nur wegen chromium müßte ich meinen Rechner von 8 GB auf 32 GB RAM aufrüsten ?

Hat denn jemand so ein starkes System......und vor allen Dingen.....gehts dann schneller ?

----------

## flammenflitzer

Gab es da nicht mal vor vielen Jahren die Möglichkeit in Portage Pakete über "binary package host" oder so ähnlich zu installieren? Weiß nicht mehr genau, wie das war. Ich bin der Meinung, das ich in der Anfangszeit nicht jedes Stück Software selbst kompilieren musste....

Schade, das es das nicht (mehr) -zumindest für Software ab einer bestimmten Größe- gibt. (Ich glaube bei qtwebkit habe ich das letzte Mal den Rechner ewig angelassen....)

----------

## Tyrus

Hm, also ich hatte heute auch ein Rebuild auf die qtwebengine. Zum wiederholten Mal, es gab ein Update für dev-libs/protobuf das den Rebuild dann ausgelöst hat. 

Compiletime der qtwebengine ist sicher auch bei mir so 4 Stunden geschätzt. 

Mein System ist mit i3-6100 Duo @ 3.7GHz und 8 GB Hauptspeicher sicher auch nicht das allerschnellste aber ich bin zufrieden eigentlich.

Vor zwei Wochen oder so gabs ein Update für dev-libs/icu und wups war da auch die qtwebengine betroffen und um es noch deutlich länger zu ziehen war auch noch libreoffice betroffen.  :Wink: 

Ist halt manchmal auch einfach Pech. Liegt dran wie oft ich Updates hole und installiere ob ich Dinge gefühlt doppelt und dreifach machen muss. Manchmal kann man auch mehrere Sachen auf einmal erfassen wenn man nicht zu oft Updates fährt. Grundsätzlich ist Gentoo aber doch eine sourcebasierte Distro mit Rolling Releases. Da ist das dann eben so das es auch große Brocken gibt. Ich möchte die aber auch selber compilieren muss ich sagen. 

Vielleicht gibts irgendwo ein Overlay das Binary-Pakete zur Verfügung stellt. Ich hab nie danach gesucht. Wäre jedenfalls ein Gedanke wenn da die Nachfrage ausreichend groß ist.

Der große Vorteil von Gentoo ist doch die enorme Freiheit Pakate nach eigenen Wünschen anzupassen und hardwareoptimierter zu compilieren. Grade für große Brocken find ich Performancegewinne doch grade interessant.

Gut wenn mich so ein Update echt grade mal nervt weils zu lange dauert, dann kann man das auch mal ne Woche oder zwei mittels der Exclude-Option beim Emerge ausklammern. Ich musste ja heute nicht zwingend dev-libs/protobuf updaten.

----------

## LuxJux

Im Prinzip geb ich dir ja recht. Da reichen auch 2 GB RAM

Nur nicht zum gcc-übersetzen

----------

