# Wieder mal über Abhängigkeiten und Inkonsistenzen

## Mr. Anderson

Wie passt das zusammen?

```
$ emerge -ep @system | grep busybox

[ebuild     U ] sys-apps/busybox-1.12.2-r1 [1.11.1]

$ 
```

```
$ emerge -ep @world | grep busybox

$ 
```

----------

## mv

Du hast das @system-set nicht in Deinen world_sets eingetragen; vermutlich hast Du portage-2.2 in den ersten Testing-Versionen installiert, da wurde das noch nicht erzwungen. M.E. sehr sinnvoll, da so beispielsweise emerge -e @system && emerge -e @world nicht ganz so viel doppelt compiliert.

----------

## Max Steel

MAn kann mit portage-2.2 auch emerge -ep @system @world geben, das wäre genauso wie wenn das system-set in der /var/lib/portage/world_set(s ?) eingetragen ist.

----------

## Mr. Anderson

Danke, ich habe nun @system in /var/lib/portage/world_sets eingetragen. IMO ist es zwingend, dass @system von @world impliziert wird, denn sonst hieße das ja, dass ein ebuild aus @world nicht @system impliziert, was aber nach den Richtlinien für ebuilds notwendig ist, damit man nicht für jedes ebuild die ganze Palette an Paketen aus @system als Abhängigkeit angeben muss.

----------

## Necoro

Sets "implizieren" überhaupt nix. Sets sind einfach nur Vereinfachungen für bestimmte Pakete:

- @system: Alle Pakete, die als "Grundsystem" vom Profil vorgegeben werden

- @world: Alle Pakete, die der Nutzer installiert haben will - ergo im WorldFile stehen

- @installed: Alle installierten Pakete

- @live-rebuild: Alle installierten live pakete

etc.

Und ich persönlich will @system nicht in @world haben. Weil die Sachen, die vom Profil vorgegeben sind, müssen zwar installiert sein, sie sind es aber net auf meinen Wunsch hin.

Das Ebuilds die System-Pakete voraussetzen können hat mit den Paket-Sets daher nichts zu tun...

----------

## Mr. Anderson

Hm. Dann wird @installed wohl @world ablösen, wenn man alle Pakete will, die installiert sind. Denn darum geht es ja schließlich den meisten, wenn sie ihr komplettes System aktualisieren wollen. Auf diese Weise ergibt alles auf einmal Sinn. Eine typische Zeile, die früher in etwa

```
emerge world -uDN --with-bdeps
```

war, wird dann wohl

```
emerge @installed -uN
```

was wesentlich kürzer ist.

----------

## Max Steel

ICh denke eher nicht, viele wollen zwar ein rundum aktuelles System, aber niemand möchte Jahrealte Altlasten die keiner mehr braucht, und das wird durch @installed impliziert.

Also lieber @world nutzen und alle paar mal --depclean hinterherjagen, geht ja auch auf die Speicherkapazität der FP, sowie der Performance.

----------

## Mr. Anderson

Ein --depclean kann man ja trotzdem immer mal wieder ausführen. Vom Sicherheitsaspekt ist es wohl schon sinnvoll, wenn auch die Altlasten auf dem aktuellen Stand bleiben bis sie entfernt werden.

----------

## Max Steel

Okay, da hast recht.

----------

## Mr. Anderson

Nein, ich habe nicht Recht  :Smile: 

Habe das eben mal genauer angesehen. Alle slotted ebuilds werden dann unnötigerweise in ihrer neuesten Version installiert, auch wenn die völlig unnütz ist (z. B. qt 4.x, weil qt 3.x installiert ist). Dann bleibt es wohl vorerst bei @world und ggf. @system.

----------

## mv

Es empfiehlt sich die Erstellung eines sets @all, das die Sets @world und @system enthält. Und --with-bdeps y hat man bei Systemen, die für sich selbst selbst kompilieren, ohnehin in /etc/make.conf bei den Default-Optionen eingetragen.   :Wink: 

So hat man dann nur noch 

```
emerge -NaDu @all
```

 für normale Updates oder 

```
emerge -eD @all
```

 für volle Recompilation zu tippen (ich weiß, das letzte D wäre überflüssig, aber es ist klarer).

----------

## mv

 *Mr. Anderson wrote:*   

> Alle slotted ebuilds werden dann unnötigerweise in ihrer neuesten Version installiert, auch wenn die völlig unnütz ist (z. B. qt 4.x, weil qt 3.x installiert ist).

 

Das ist faslch. qt-4 beispielsweise wird (mit emerge -NDu @world @system) nur gebaut, wenn irgendetwas von qt:4 abhängt, oder wenn Du qt in Deinem world-File hast: Im letzten Fall nimmt portage natürlich (zu Recht) an, dass Du an qt (und damit natürlich am neuesten Slot) interessiert bist.

----------

## mv

 *Mr. Anderson wrote:*   

> Ein --depclean kann man ja trotzdem immer mal wieder ausführen. Vom Sicherheitsaspekt ist es wohl schon sinnvoll, wenn auch die Altlasten auf dem aktuellen Stand bleiben bis sie entfernt werden.

 

Statt unnötig zu updaten, lieber gleich entfernen: Das ist nicht nur die sicherste sondern auch die schnellste Variante.

Und falls man --depclean-faul ist: Ob man etwas vergessen hatte, kann man ja ganz fix mit eix -uc überprüfen: Wenn das etwas ausgibt, weiß man, dass ein --depclean nötig ist; und wenn nicht, ist man sowieso auf dem neuesten Stand, auch von ev. unbenötigten Paketen.

----------

## Mr. Anderson

 *mv wrote:*   

>  *Mr. Anderson wrote:*   Alle slotted ebuilds werden dann unnötigerweise in ihrer neuesten Version installiert, auch wenn die völlig unnütz ist (z. B. qt 4.x, weil qt 3.x installiert ist). 
> 
> Das ist faslch. qt-4 beispielsweise wird (mit emerge -NDu @world @system) nur gebaut, wenn irgendetwas von qt:4 abhängt, oder wenn Du qt in Deinem world-File hast: Im letzten Fall nimmt portage natürlich (zu Recht) an, dass Du an qt (und damit natürlich am neuesten Slot) interessiert bist.

 

Ich meinte ja auch, was passiert, wenn ich emerge -uN @installed verwende  :Smile: 

----------

