# [gelöst] Einige ebuilds werden nicht upgedatet

## wuesti

```
eix-sync

 * Starte eix-diff

[U]   == dev-util/cmake (2.8.9@31.03.2013; 2.8.9 -> 2.8.10.2-r2): Cross platform Make
```

...zeigt, dass cmake von 2.8.9 auf 2.8.10.2-r2 upgedatet werden soll.

```
emerge -avuDN world

These are the packages that would be merged, in order:

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 kB

Nothing to merge; would you like to auto-clean packages? [Yes/No] 
```

...führt das Update nicht aus, aber ...

```

emerge -pv cmake

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild     U  ] dev-util/cmake-2.8.10.2-r2 [2.8.9] USE="ncurses -emacs -qt4 {-test} -vim-syntax" 5,634 kB

Total: 1 package (1 upgrade), Size of downloads: 5,634 kB
```

... würde es machen.

Auf diese Weise sammeln sich im Laufe der Zeit so einige Pakete an, die eigentlich upgedatet werden sollten. Vor etwa einem Monat waren es mehr als 30. Jetzt sind es auch schon wieder 5.

```
emerge -pv --emptytree world

....

Total: 931 packages (5 upgrades, 1 in new slot, 925 reinstalls), Size of downloads: 1,070,508 kB
```

Was läuft da falsch?Last edited by wuesti on Sun Apr 28, 2013 6:23 am; edited 1 time in total

----------

## mv

Du willst emerge --with-bdeps=y. Meiner Meinung nach sollte das Default sein, aber das kannst Du ja leicht selbst reparieren:  */etc/portage/make.conf wrote:*   

> EMERGE_DEFAULT_OPTS=--with-bdeps=y

 

----------

## Max Steel

 *mv wrote:*   

> Du willst emerge --with-bdeps=y. Meiner Meinung nach sollte das Default sein, aber das kannst Du ja leicht selbst reparieren:  */etc/portage/make.conf wrote:*   EMERGE_DEFAULT_OPTS=--with-bdeps=y 

 

richtig. Der Gedanke dahinter das standardmäßig with-bdeps ausgeschaltet ist, ist der das build-time-deps in der Regel keine Sicherheitsbugs erzeugen, also spart man sich einfach diese Compilezeit und lässt sie bei Bedarf (falls durch eine neue VErsion eines Pakets oder ein neues Paket ansich eine neuere Version gebraucht wird) dieses geupdatet wird.

----------

## mv

 *Max Steel wrote:*   

> Der Gedanke dahinter das standardmäßig with-bdeps ausgeschaltet ist, ist der das build-time-deps in der Regel keine Sicherheitsbugs erzeugen

 

Das ist nicht richtig: Sicherheitsbugs einer Interpretersprache, auch wenn sie ursprünglich nur zum Bauen von etwas anderem auf das System geholt wurde, können durchaus kritisch sein.

Erst recht gilt das für Pakete, die von solchen Dingen abhängen. Beispielsweise hängt cmake von curl ab, das für viele User nur dadurch auf das System kommt und das durchaus sicherheitskritisch ist.

----------

## Max Steel

 *mv wrote:*   

>  *Max Steel wrote:*   Der Gedanke dahinter das standardmäßig with-bdeps ausgeschaltet ist, ist der das build-time-deps in der Regel keine Sicherheitsbugs erzeugen 
> 
> Das ist nicht richtig: Sicherheitsbugs einer Interpretersprache, auch wenn sie ursprünglich nur zum Bauen von etwas anderem auf das System geholt wurde, können durchaus kritisch sein.
> 
> Erst recht gilt das für Pakete, die von solchen Dingen abhängen. Beispielsweise hängt cmake von curl ab, das für viele User nur dadurch auf das System kommt und das durchaus sicherheitskritisch ist.

 

Hmmm bei Interpretersprachen wie Python, Perl und co (also auch JAVA) kann ich das durchaus verstehen. Aber dann gehören diese eher in die Runtime dependencies... Build Time Deps sind wie der Name schon sagt "nur" buildtimedeps also z.B. gcc, make, binutils und co.

Zumindest verstand ich das so bislang.

----------

## Necoro

 *Max Steel wrote:*   

>  *mv wrote:*    *Max Steel wrote:*   Der Gedanke dahinter das standardmäßig with-bdeps ausgeschaltet ist, ist der das build-time-deps in der Regel keine Sicherheitsbugs erzeugen 
> 
> Das ist nicht richtig: Sicherheitsbugs einer Interpretersprache, auch wenn sie ursprünglich nur zum Bauen von etwas anderem auf das System geholt wurde, können durchaus kritisch sein.
> 
> Erst recht gilt das für Pakete, die von solchen Dingen abhängen. Beispielsweise hängt cmake von curl ab, das für viele User nur dadurch auf das System kommt und das durchaus sicherheitskritisch ist. 
> ...

 

Das verstehst du auch richtig. Solch ein Paket hat Python et al. dann sowohl in DEPEND als auch in RDEPEND. Es gibt zugegeben nur relativ wenige "reine" build-time deps (gcc, autotools, cmake, intltool, teilweise boost), denn das meiste Zeugs stellt ja Libraries zur Verfügung, die auch zur Ausführung benötigt werden.

----------

## mv

 *Max Steel wrote:*   

> Hmmm bei Interpretersprachen wie Python, Perl und co (also auch JAVA) kann ich das durchaus verstehen. Aber dann gehören diese eher in die Runtime dependencies...

 

Nur wenn sie auch zur Laufzeit benutzt werden. Typisches Gegenbeispiel: ant wird (statt make) zum Bauen benutzt. Dieses braucht ein lauffähiges Java. Wenn das Projekt selbst kein Java-Projekt ist, gibt es keinen Grund, Java als Runtime dependency zu haben.

Anderes Beispiel: Coreutils (neuere Versionen) benutzen Perl nur zum Bauen der manpage: eine klassische nur-buildtime-Dependency an Perl.

Aber ganz unabhängig davon: Indirekte dependencies von Runtime-Dependencies gehen eben auch ohne --with-bdeps=y verloren. Da dies fast beliebige Programme sein können (z.B. makeinfo->texlive->tausende von Paketen), ist aktualisieren ohne --with-bdeps=y auf jeden Fall ein Sicherheitsproblem. Wie gesagt, ich verstehe nicht, weshalb das nicht Default ist: In den paar Fällen, in denen man ausschließlich woanders bauen und nur Binärpakete einspielen will, könnte man dem Benutzer leicht zumuten, manuell EMERGE_DEFAULT_OPTS="--with-bdeps=n" zu setzen - gerade weil der umgekehrte Fall leichter übersehen wird, vor allem von Newbies, und diese sich damit ein Sicherheitrisiko einhandeln können.

----------

## Necoro

 *mv wrote:*   

> Anderes Beispiel: Coreutils (neuere Versionen) benutzen Perl nur zum Bauen der manpage: eine klassische nur-buildtime-Dependency an Perl.

 

Da man tendenziell aber auch reine Perl-Pakete installiert hat, ist das aber unwichtig/

 *Quote:*   

> Aber ganz unabhängig davon: Indirekte dependencies von Runtime-Dependencies gehen eben auch ohne --with-bdeps=y verloren.

 

Nö. Dazu gibts ja "--deep"

 *man emerge wrote:*   

> This  flag  forces  emerge to consider the entire dependency tree of packages, instead of checking only the immediate dependencies of the packages.  As an example, this catches updates in libraries that are not directly listed in the dependencies of a package.

 

Ich sehe gerade  überhaupt nicht, was dich auf den Zusammenhang "indirekte libs" und "--with-bdeps=y" bringt. Das sind doch zwei disjunkte Paar Schuhe.

----------

## mv

 *Necoro wrote:*   

>  *mv wrote:*   Anderes Beispiel: Coreutils (neuere Versionen) benutzen Perl nur zum Bauen der manpage: eine klassische nur-buildtime-Dependency an Perl. 
> 
> Da man tendenziell aber auch reine Perl-Pakete installiert hat, ist das aber unwichtig

 

Vielleicht, vielleicht auch nicht. Es gibt ja auch noch andere Interpretersprachen für die ähnliches gilt. Und wenn es tendentiell egal ist, dann könnte man ja ohnehin --with-bdeps=y als Default machen.

 *Quote:*   

>  *Quote:*   Aber ganz unabhängig davon: Indirekte dependencies von Runtime-Dependencies gehen eben auch ohne --with-bdeps=y verloren. 
> 
> Nö. Dazu gibts ja "--deep"

 

Du glaubst also, dass bei --with-bdeps --deep zwar die build-time-dependencies selbst ausgenommen, deren dependencies aber trotzdem dazugenommen werden? Das habe ich nicht ausprobiert (und im Moment sitze ich auch nicht vor einem Gentoo-Rechner), aber das würde mich sehr überraschen: Das würde bedeuten, dass ich z.B. auf einem kleinen Rechner, der nur Binärpakete einspielen soll, die ggf. riesigen Abhängigkeiten von build-time-dependencies bauen müsste, obwohl es gar keinen Grund gäbe, die auf diesem Rechner zu haben. Das würde die Bedeutung von build-time-depedencies vollkommen konterkarieren.

----------

## Necoro

 *mv wrote:*   

>  *Necoro wrote:*    *mv wrote:*   Anderes Beispiel: Coreutils (neuere Versionen) benutzen Perl nur zum Bauen der manpage: eine klassische nur-buildtime-Dependency an Perl. 
> 
> Da man tendenziell aber auch reine Perl-Pakete installiert hat, ist das aber unwichtig 
> 
> Vielleicht, vielleicht auch nicht. Es gibt ja auch noch andere Interpretersprachen für die ähnliches gilt. Und wenn es tendentiell egal ist, dann könnte man ja ohnehin --with-bdeps=y als Default machen.

 

Ja ok. Ich glaube trotzdem, dass die Diskussion eher akademisch ist.

 *Quote:*   

>  *Quote:*    *Quote:*   Aber ganz unabhängig davon: Indirekte dependencies von Runtime-Dependencies gehen eben auch ohne --with-bdeps=y verloren. 
> 
> Nö. Dazu gibts ja "--deep" 
> 
> Du glaubst also, dass bei --with-bdeps --deep zwar die build-time-dependencies selbst ausgenommen, deren dependencies aber trotzdem dazugenommen werden?

 

Nein, natürlich nicht. --deep ≡ RDEPEND^+ -- aber so hatte ich dich auch verstanden.

Pakete, von denen nur build-deps abhängen und nix anderes sind mir in der Regel herzlich egal  :Smile: .

----------

## mv

 *Necoro wrote:*   

> Nein, natürlich nicht. --deep ≡ RDEPEND^+ -- aber so hatte ich dich auch verstanden.
> 
> Pakete, von denen nur build-deps abhängen und nix anderes sind mir in der Regel herzlich egal :).

 

Ich bin nicht sicher, ob wir uns richtig verstehen: Wenn beispielsweise texlive nicht im world-File steht (und auch nicht indirekte RDEPEND davon ist) - bei Leuten, die keine wissenschaftlichen Texte schreiben, vielleicht gar nicht so selten - andererseits aber texlive als build-time dependency für das Bauen irgendeiner Dokumentation benötigt wird, dann wird emerge -Nu --deep @world eben nicht texlive und auch keine einzige der hunderten Abhängigkeiten von texlive updaten (außer denjenigen, die zufälligerweise indirekte RDEPENDS von anderen Paketen im world-file sind). Für einen Newbie, der nicht weiß, dass er eigentlich immer --with-bdeps=y benutzen sollte, ist das dann keine akademische Frage, sondern er handelt sich unwissentlich ein massives Sicherheitsproblem ein.

----------

## Necoro

Ah - du meinst jemanden, der zufällig (via DEPEND) texlive installiert hat und es dann auch aktiv nutzt? (Dito für Python, Java, what else). Ja ok -- das ist natürlich böse. Aber wer macht sowas  :Shocked:  ?

----------

## mv

 *Necoro wrote:*   

> Aber wer macht sowas  ?

 

Newbies; die dann oft nicht wissen, dass es --with-bdeps=y gibt.

----------

