# --exclude= und warum es hilfreich ist.

## YPenguin

Zum Updaten habe ich ein Miniscript (Name: systemupdate) mit nur einer Zeile:

emerge --update --deep --with-bdeps=y --newuse --backtrack=30 --ask --exclude=icu world

systemupdate lines 1-1/1 (END)

Wenn ein Update jede Menge Rebuilds verursacht - wie derzeit icu - dann setze ich das erstmal auf die Exclude-Liste

und warte einige Zeit ab. Dadurch spare ich Zeit beim Kompilieren.

----------

## Josef.95

Hm, ich denke das es keine gute Idee ist Sicherheitsupdates via --exclude Option auszuschließen - das schafft auf dauer gesehen wahrscheinlich eher mehr Probleme als nutzen.

Und das letzte stable icu Update 

```
eix -e icu

[I] dev-libs/icu

     Available versions:  55.1(0/55) ~56.1(0/56) ~56.1-r1(0/56.C++11) {debug doc examples static-libs ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"}

     Installed versions:  55.1(08:39:24 PM 12/14/2015)(-debug -doc -examples -static-libs ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32")

     Homepage:            http://www.icu-project.org/

     Description:         International Components for Unicode
```

 ist doch auch schon ne Zeitlang her.

Oder nutzt du eventuell jedes Update aus dem  Testing-Zweig?

Falls ja, und dir das viele kompilieren zu viel ist, dann nutze besser die stable Version - dort gibt es wesentlich weniger Updates und rebuilds.

----------

## YPenguin

Ich habe ~amd64 akzeptiert und eigentlich kaum Probleme damit.

----------

## Josef.95

Ja ok, mag ja sein. Aber beachte das du mit --exclude=icu *alle* Versionen (auch die stable Sicherheitsupdates) dieses Pakets (inklusive deren ggf weiteren Deps) ignorierst - sowas will man idR nur für temporäre Ausnahmefälle.

Wenn du nur eine bestimmte Version von icu haben möchtest, dann würde ich diese in der package.accept_keywords wie benötigt setzen.

Du kannst (wenn du global ~arch freigeschaltet hast) in der package.accept_keywords auch einzelne Pakete wieder auf stable setzen, exakt gewünschte Versionen setzen usw

--exclude sollte man dafür nicht missbrauchen müssen.

----------

## franzf

Wirklich schneller wird das nicht sein. Du bekommst halt das eine Update schneller durch, aber ICU wirst du irgendwann aktualisieren müssen. Mit etwas Pech gab es aber auch ein Update eines Pakets, das ICU benötigt. Dann darfst du das gleich zweimal bauen: einmal das Update ohne neuem ICU, dann nochmal nach dem ICU-Update  :Wink:  Dann kompilierst du insgesamt sogar länger  :Razz: 

Für mich nützlich war das feature:

 wenn ein Paket die ABI in ner lib ändert, aber die SOVERSION nicht anpasst. Dann kann man ein revdep-rebuild auf die lib laufen lassen aber das Paket mit der bösen lib selbst ausschließen (braucht ja nicht nochmal gebaut werden). Aktueller Anwendungsfall war: openssl.

 Ich weiß genau, dass einzelne große Pakete zur Zeit ein Problem haben und nicht kompilieren, ein Fix für mich aber noch nicht bekannt ist. Hatte ich kürzlich bei calligra (clang: bricht ab mit std::bad_alloc. Lösung: -DWITH_GMIC=OFF), hugin (clang-3.7 läuft in nen SEGFAULT. Lösung: clang-3.8 schafft es) und vor einiger Zeit webkit-gtk (>40 Minuten nur beschäftigt mit "scanning dependencies of target XYZ. Lösung: cmake generator von Makefile auf ninja umstellen)

 Ein Enduser-Programm (also keine lib), das ich sehr selten benutze, braucht dank ABI-change in ner lib ein rebuild. Der rebuild dauert extrem lange und ich weiß, dass ich das Programm die nächste Zeit eh nicht brauche. Hatte ich schön öfter mit inkscape, das durch poppler-ABI-change zu nem rebuild genötigt wurde.

----------

## YPenguin

Wenn man ~amd64 gewählt hat, kommt es schon häufiger mal vor, dass ein Paket nicht installiert. Gerade in den letzten Wochen waren gehäuft Fälle zu beobachten. Auch da setze ich auf die Exclude-Methode - oft wird der Fehler recht bald behoben. Übrigens ist das ein Grund bei Problemen nicht gleich das ganze System neu aufsetzen zu wollen*, sondern lieber die laufenden alten Versionen zu behalten.

----------

## YPenguin

*Bezug auf meine Threads zu Python-Problemen.

----------

## Josef.95

Puh, ich verstehe nicht was du hier machst..

Sich ein Updatescript zu basteln, und das mit --exclude zu spicken, halte ich immer noch für eine der schlechtesten "lösungen"

welche idR nur weitere Probleme nach sich zieht.

Für so einen "Missbrauch" ist die --exclude Option auch nicht vorgesehen.

----------

## Klaus Meier

Ich kann mich entsinnen, dass ich dieses Update von icu auf verflucht habe, weil es Libreoffice und ähnliche Klopfer neu bauen wollte. Aber das kam jetzt genau einmal vor, ist also nicht so häufig, dass man es permanent ausschließen sollte. Und vor allem, wie Josef ja auch schon sagte, ist es ja auch nicht garantiert, dass jedes Update von icu zu Rebuilds führt.

Und ansonsten ist das ganze aktuell auch kein Problem, weil standardmäßig die Option "preserve-libs" gesetzt ist. Die bewirkt, dass bei einer neuen, inkompatiblen Version einer Bibliothek, die alte parallel zu der neuen installiert bleibt. So funktionieren deine Anwendungen alle weiter. Die alte Version dieser Bibliothek wird erst gelöscht, wenn alle Rebuilds durch sind. Ich lasse die dann über Nacht laufen und kann trotzdem weiter arbeiten.

In früheren Zeiten gab es diese Option noch nicht und man musste manuell mit revdeü-rebuild nach nötigen Rebuilds suchen. Und keine dieser Anwendungen funktionierten dann weiter, bis halt das Rebuild durch war. Aber wie gesagt, aktuell alles kein Problem mehr.

----------

## Josef.95

Hm nee, das preserve-libs FEATURE (oder auch revdep-rebuild) ist eher für Pakete mit einem SONAME Change vorgesehen.

Bei Paketen wie dev-libs/icu, app-text/poppler, oder auch xorg-server gibt es aber beim Update mitunter einen ABI Wechsel, der so weder mit revdep-rebuild oder dem preserve-libs Feature erkennbar ist ohne SONAME Wechsel - das ist mit der hauptsächliche Grund warum man die Subslots eingeführt hat.

(man denke an die alten Zeiten, wo die Treiber nach einem xorg-server Update ohne Treiber rebuild plötzlich nicht mehr kompatibel waren - sowas kann man heute fein mit den Subslot rebuilds vermeiden).

..................................................................

Und nochmal kurz zum Topic:

YPenguin, wenn du ein Update (aus was für Gründen zZt auch immer)  nicht machen möchtest, dann maskiere die unerwünschte Version doch besser in den /etc/portage/package.* Dateien - so wie das normal vorgesehen ist.

Updates via --exclude Option zu unterdrücken ist meiner Meinung nach die schlechteste aller vorhandenen Möglichkeiten - unter anderem auch weil man damit nicht nur das via --exclude Option ausgeschlossene Paket ausschließt, sondern auch die Deps von dem Paket mit - und das will man idR nicht, zb weil man dann für das Paket und deren Deps keine Sicherheitsupdates mehr nutzt.

Beispiel: firefox benötigt zum bauen auch dev-libs/nss

wenn du nun via --exclude Option firefox ausschließest, dann wird portage auch keine Updates für dev-libs/nss mehr berücksichtigen, da es keine Dep mehr drauf gibt.

Sorry, aber sowas will normalerweise kein Mensch, und ist so ja auch nicht vorgesehen. Daher halte ich deine Vorgehensweise Updates via --exclude zu unterdrücken für eine sehr schlechte Idee.

----------

## mv

 *Josef.95 wrote:*   

> Bei Paketen wie dev-libs/icu, app-text/poppler, oder auch xorg-server gibt es aber beim Update mitunter einen ABI Wechsel, der so weder mit revdep-rebuild oder dem preserve-libs Feature erkennbar ist ohne SONAME Wechsel

 

Ich wäre überrascht, wenn die icu-Versionsn 55.*, 56.*, 57.* keinen soname-Wechsel brächten; die 56.1-r1 scheint eine spezielle Ausnahme zu sein.

Und bei poppler ist es m.W. so, dass die Politik der Subslots nach hinten losgeht: Die "Hauptbibliothek" macht ordentlich ihren soname-Wechsel, aber wegen irgendwelcher experimentellen Bibliotheken, die praktisch niemand benutzt, wird der Subslot geändert und alles unnötigerweise neu kompiliert. Deswegen gingen die großen Brocken wie libreoffice m.W. jetzt dazu über, den Subslot von poppler zu ignorieren - und damit die alten revdep-rebuild Probleme zu reproduzieren: Die Gentoo-Maintainer von poppler und libreoffice konnten sich m.W. nicht auf eine gemeinsame vernünftige Politik einigen.

----------

## Klaus Meier

Josef, was soll ich sagen, wirst du alt? Genau darum geht es doch, dass man bei einem ABI-Wechsel auch einen Soname-Change durchführt. Alles andere ist doch Schwachsinn. Wir hatten doch gerade einen ABI-Wechsel ohne Soname-Change. Mit der Folge, das es einen ganz großen Peng gab. Mit einem manuellen Rebuild. Und warum sollte ich einen Soname-Change machen, wenn sich an der ABI nichts geändert hat?

Da gibt es schon ein sehr gut funktionierendes System. An welches sich die meisten auch halten. Leider nicht alle, das ist das Problem.

P.S.: Aber solche Diskussionen sind etwas, die dafür sorgen, dass Neulinge erst mal vergrault werden. Wenn ich so daran denke, was hier los war, als ich neu bei Gentoo war. 99% aller Beiträge stammen doch aktuell von Personen, die schon ewig dabei sind. Neulinge werden hier einfach nur vergrault. Vielleicht kapieren das ja einige hier irgendwann mal.

Linux leidet unter seinen Selbstdarstellern mit sozialen Problemen. Und es ist sehr schade, dass ich so etwas hier öffentlich schreiben muss, PMs haben nichts genutzt. Leider ist es oft so, dass sich die schlechtere Lösung durchgesetzt hat, weil es da Menschen gibt, die nicht in der Lage sind, miteinander zu Reden.

----------

## Josef.95

Klaus,

sorry nein, ich werde nicht alt - ich bin schon alt (ja ich bin über fünfzig).

Und nein, Downstream kann und sollte nicht ständig SONAME Wechsel machen bei einem ABI Wechsel - das ist Aufgabe von Upstream

wie beispielsweise beim xorg-server.

Und genau für solche Zwecke (wo es zb ein ABI Wechsel ohne SONAME Change gibt) wurden ja mit EAPi5 die nötigen rebuilds via Subslots eingeführt bzw ermöglicht das automatisch mit zu erledigen.

Und nein, es ist nicht meine Absicht Neulinge zu vergraulen. Ich finde es nur nicht gut wenn man

sich auf dem System global ~arch freischaltet, sich dann über viele Testing-Updates wundert, und dann versucht diese Updates via --exclude Option zu verhindern,

und dies auch noch als eine gute Vorgehensweise versucht an den Mann zu bringen.

Die --exclude Option ist fein, ja, für temporäre Zwecke aus der Shell heraus - aber nicht um sie in emerge_default_opts oder UpdateScripte dauerhaft zu verwenden. Für sowas sind die dafür vorgesehenen /etc/portage/package.* Dateien wesentlich besser geeignet.

Klaus, ich bin stets offen für neue gute Ideen, aber ich finde es nicht gut wenn man schlechte Ideen nicht mehr kritisieren darf, und nun ständig von dir als "Neulingsschreck" hingestellt wird.

Und dein Glaube das hier im Forum weniger los ist als früher, nur weil man eine schlechte Idee auch mal kritisiert - nein daran glaube ich nicht. Die Diskussionen waren hier früher mitunter deutlich härter.

Das hier im Forum weniger los ist liegt meiner Meinung daran das Gentoo sich in den letzten Jahren weiterentwickelt hat, und es einfach deutlich weniger Probleme gibt als noch vor 5 oder 10 Jahren.

----------

## YPenguin

Bei mir geht es nur um meinen eigenen Desktop-Rechner.

Ansonsten kann ich es schon verstehen, dass man Sicherheitsupdates wahrnimmt, wenn es um mehr geht.

----------

## mv

 *YPenguin wrote:*   

> Bei mir geht es nur um meinen eigenen Desktop-Rechner.
> 
> Ansonsten kann ich es schon verstehen, dass man Sicherheitsupdates wahrnimmt, wenn es um mehr geht.

 

Ein eigener Desktop-Rechner ist von Sicherheitslücken genauso gefährdet, wie ein Firmenrechner oder Server; sogar mehr, weil Du vermutlch keine so starke Backup-Politik hast und auch keine weiteren Systeme, die Auffälligkeiten des Rechners melden könnten: Das Problem bei Desktop-Rechnern ist nicht nur ein Angriff auf Deine Privatsphäre, sondern, dass Dein Rechner als Teil eines Bot-Netzes, z.B. von Versenden von Spam oder anderen illegalen Aktivitäten benutzt wird. Es gab mal ein vielzitiertes Posting eines Windows-Benutzers, der sich gewundert hatte, dass sein Festplattenspeicher schnell abnahm, und der dann Kinderpornos auf seinem Rechner entdeckt hatte, die offensichtlich ein illlegales Netzwerk zur Verbreitung dort zwischengespeichert hatte... Heutzutage würde so etwas vermutlich nicht mehr so naiv ohne Verschlüssselung ablaufen, aber im Prinzip immer noch das selbe.

Inhaltlich muss ich allerdings Josef.95 zustimmen: --exclude ist nicht zur dauerhaften Benutzung gedacht, sondern als "one-shot"-Option (ich weiß keine passendere Übersetzung für diesen Anglizismus). Zur dauerhaften Benutzung sind /etc/portage/package.mask u.ä. vorgesehen. Du kannst Dir ein Directory mit diesem Namen anlegen, und das, was Du sonst mit --exclude eingegeben hättest, in eine eigene Datei in diesem Directory schreiben: Einfach alle größeren Versionen als die aktuell installierten maskieren.

Möglicherweise kann das sogar inhaltlich einen Unterschied machen: Ich hatte einige Fälle, in denen Portage den Abhängigkeitsbaum bei --exclude-Paketen abzuschneiden schien. Wenn Du also z.B. --exclude=icu hast, wird nicht nur icu selbst von Updates ausgenommen, sondern ggf. ebenfalls Pakete, die nur von icu abhängen (und sonst von nichts anderem). Möglicherweise betraf das damals nur DEPEND-Abhängigkeiten (also nicht RDEPEND) oder vielleicht sogar nur PDEPEND: Ich hatte nicht weiter nachgeforscht und hielt es nicht für weiter wichtig, weil - wie gesagt - eben --exclude nur als "one-shot"-Option gedacht ist.

 *Josef.95 wrote:*   

> Das hier im Forum weniger los ist liegt meiner Meinung daran das Gentoo sich in den letzten Jahren weiterentwickelt hat, und es einfach deutlich weniger Probleme gibt als noch vor 5 oder 10 Jahren.

 

Ich fürchte, es gibt deswegen weniger Probleme, weil die Benutzergruppe von Gentoo älter geworden ist, und kaum Junge hinzukommen. Dass potentielle Junge aber durch das Forum abgeschreckt werden, kann ich mir ebenfalls nicht vorstellen. Gentoo ist halt einfach nicht mehr "hipp" bei der Smartphone-Generation: Ricer bemerken keinen Zeitunterschied bei ihren Anwendungen, und wer aus Sicherheitgründen ein angepasstes System will, ist halt meistens schon abgeklärter und hat viel Erfahrung.

----------

## Josef.95

@mv,

du hast es ein wenig besser formuliert, und das ganze ziemlich gut auf den Punkt gebracht. Deinen Ausführungen stimme ich so ziemlich voll und ganz zu.

Dankeschön.

----------

## Josef.95

@YPenguin

Hier ist grad ein schönes Beispiel wie man mit so einem Vorgehen auf die Nase falle kann --> https://forums.gentoo.org/viewtopic-t-1044116.html

----------

