# emerge world MANUELL ? Geht das ?

## tobiasbeil

Mal ne ganz dumme frage, die ich mir hab einfallen lassen:

angenommen man merkt sich alle packete, welche

```
emerge -bDeNupv world
```

...ausgibt, die Reihenfolge inklusive.

Ist dann das emergen jedes einzelnen packetes in der Reihenfolge

einem emerge -... world äquivalent ???

ja oder nein ?

oder kommt-darauf-an ?

 :Shocked:   :Question:   :Question:   :Question: 

----------

## Blood_Seeker

Also meines wissens kannst du jedes Paket von Hand updaten ( aber warum sollte man das wollen? ).

Und die reienfolge ist au egal weil portage alles zusammensucht was das Paket zum kompilieren braucht und das auch in der richtigen reienfolge.

zb. du willst das Paket nvidia-glx updaten dieses hat aber die Abhängigkeit nvidia-kernel also merged portage dann automatisch beide.

----------

## slick

Ich kann zwar für meine Teil nicht den Sinn der Frage erkennen, aber prinzipiell ist es doch so:

emerge -p... world zeigt wir an welche Paket portage in welcher Reihenfolge installieren würde um "world" upzudaten. Mergst Du jetzt diese Pakete in dieser Reihenfolge selbst, kommt das dem gleich. 

Anders formuliert: Wenn Du jemand an einen Rechner setzt, auf dem Du die Paket einzeln nacheinandern oder per emerge world installiert hast, wird er mit Ausnahme über das Logfile den Unterschied nicht erkennen können. 

Und letztendlich zählt doch nur das "world" up-to-date ist, wie man das erreicht ist doch jedem seine Sache.

----------

## UncleOwen

 *tobiasbeil wrote:*   

> Ist dann das emergen jedes einzelnen packetes in der Reihenfolge
> 
> einem emerge -... world äquivalent ???

 

Ja, sofern Du emerge --oneshot oder emerge --update verwendest. Sonst werden alle Pakete ins world file eingetragen, was bei emerge world nicht der Fall ist.

----------

## tobiasbeil

Vielen Danken für die Antworten.

Hintergrund der dummen Frage war:

ich will so wenig globale use flags wie möglich,

hauptsächlich nur die negativen, welche mein

system kaputtmachen könnten.

alle anderen use flags (teils global, teils local)

gebe ich dann in einem grossen installscript

jedem emerge so mit.

ist zwar aufwändig, aber ich machs trotzdem so,

der übersicht halber.

habe vor kurzen ein recht umfangreiches colinux

gentoo 2005.0 fertiggebaut, und dann kommt 2005.1 raus!

 :Mad: 

egal habe ich mir gedacht, ich kann ja alles updaten

dann war nicht alles umsonst und daher auch die frage.

Also danke nochmal.

----------

## slick

 *tobiasbeil wrote:*   

> alle anderen use flags (teils global, teils local)
> 
> gebe ich dann in einem grossen installscript
> 
> jedem emerge so mit.

 

/etc/portage/package.use ist Dir aber bekannt oder?

----------

## tobiasbeil

hmm, nö,

aber ich gebe das trotzdem in ein installationsscript ein,

weil ich kenne nur die namen der packete,

nicht die kategorie davor, jedenfalls nicht immer.

oder ist das etwa egal ??

kann ich jetzt aus der beschreibung nicht rauslesen...

EDIT:

wenn das egal ist, dann kommt es aufs selbe hinaus,

dann verwende ich auch diese package.use, danke für den hinweis!

----------

## slick

 *tobiasbeil wrote:*   

> oder ist das etwa egal ??

 

Nein. 

 *tobiasbeil wrote:*   

> weil ich kenne nur die namen der packete,
> 
> nicht die kategorie davor, jedenfalls nicht immer.

 

Die Kategorie mußt Du schon mit angeben. Solltest Du spätestens bei einem emerge rsync oder emerge sudo merken.

Bei einem emerge -pv $paket oder emerge -pv world  siehst Du doch die Kategorie und die Useflags. Da kannst Du es auch gleich einfügen falls Du sie dauerhaft abweichend von Deinen Default-Useflags installieren willst. Macht natürlich nur Sinn wenn es wenige Pakete sind, globale Useflags für alle kannst Du ja in der make.conf festlegen.

----------

## tobiasbeil

so habe ichs ja bisher handgehabt, einfach immer alles in die globen rein,

damit ich mir beim emergen nur den namen merken muss,

dafür ist dann meine USE flag im vim editor ca 11 zeilen gross.  :Shocked:   :Shocked:   :Shocked:   :Embarassed: 

nur ich finde das einfach nicht "elegant"...

----------

## slick

mein Vorschlag: Trage in die make.conf nur die Useflags ein die Du in allen Paketen per default setzen (oder nicht setzen) willst. Weichen einzelne Pakete davon ab, dann trag dieses in package.use ein. Einmal eingerichtet brauchst Du dann nurnoch bei neuen Paketen diese extra eintragen, falls diese wieder vom Standard abweichen.

Ist sehr elegant, zumindest nach meiner Meinung.

EDIT: Beispiel:

Du möchtest alle Pakete ohne Dokumenation installieren, außer samba:

/etc/make.conf

```
USE="... -doc ..."
```

/etc/portage/package.use

```
net-fs/samba    doc
```

Last edited by slick on Mon Aug 22, 2005 12:15 pm; edited 1 time in total

----------

## pablo_supertux

 *tobiasbeil wrote:*   

> so habe ichs ja bisher handgehabt, einfach immer alles in die globen rein,
> 
> damit ich mir beim emergen nur den namen merken muss,
> 
> dafür ist dann meine USE flag im vim editor ca 11 zeilen gross.    
> ...

 

es ist 100 Mal besser package.use zu benutzen, denn da kannst du für jedes Package individelle USE Einstellungen vornehmen, was in der make.conf nicht möglich ist. In make.conf sollte man nur diese USE Vars stellen, die für alle Packages gelten und in packages.use die spezielle USE für die verschiedene Packages, das ist auch viel "eleganter", wie du sagst. Es geht auch nicht darum, elegant zu sein, sondern schlau und sich wenig Arbeit geben, weil wenn du USE="???" emerge package machst, und zwar bei jedem Paket, dann kann das unendlich lang dauern.

Meine package.use sieht z.b. so aus:

```

sys-kernel/gentoo-sources symlink -doc

app-editors/vim bash-completion cscope ruby -vim-with-x -termcap-compat

app-editors/vim-core bash-completion -termcap-compat

x11-base/xorg-x11 font-server sdk doc

x11-terms/xterm toolbar unicode

media-libs/imlib2 tiff

x11-libs/libast pcrex

www-client/opera static

media-libs/lcms tiff

dev-util/dialog -unicode

media-sound/alsaplayer flac

media-sound/xmms flac

media-libs/a52dec djbfft

media-video/mplayer cdparanoia divx4linux doc dvdread live mmxext real sse2 theora xvid svga 

media-libs/win32codecs real

app-text/acroread mozilla nsplugin

dev-db/mysql innodb

app-text/tetex doc

media-video/ffmpeg a52

media-video/avifile divx4linux dvdread imagemagick

media-video/transcode divx4linux dvdread sse2 theora

media-gfx/imagemagick doc

media-gfx/gimp doc

www-client/links svga

www-client/w3m -X

media-libs/xine-lib a52 ffmpeg speex theora vcd win32codecs 

dev-php/php -X doc gd gd-external ldap postgres

dev-php/mod_php -X apache2 doc gd gd-external ldap postgres

net-www/apache doc

media-libs/gd fontconfig

dev-db/postgresql doc

```

----------

## Genone

 *tobiasbeil wrote:*   

> Mal ne ganz dumme frage, die ich mir hab einfallen lassen:
> 
> angenommen man merkt sich alle packete, welche
> 
> ```
> ...

 

Letzteres. Es kann äquivalent sein, kann aber auch deutliche Unterschiede geben. Das fängt bei --oneshot an, geht über auto-use bis hin zu Config Updates (falls du zwischendurch etc-update laufen lässt und nicht nur am Ende).

Ausserdem kann sich evtl. auch die Reihenfolge ändern.

----------

## Anarcho

 *tobiasbeil wrote:*   

> habe vor kurzen ein recht umfangreiches colinux
> 
> gentoo 2005.0 fertiggebaut, und dann kommt 2005.1 raus!

 

Dir ist schon klar das bei Gentoo der Releasezyklus nicht wirklich viel mit den Paketen zu tun hat? Die "neue" Version beherbergt ein neues Profil (/etc/make.profile link) und ne neue LiveCD. Das wars dann auch schon für die bereits bestehenden Gentoo-User. 

Daher ist es sinnlos updates an Versions-releases anzupassen. Dann sollte man sich lieber selber feste Punkte setzen.

----------

## tobiasbeil

Ach so ist das...

Mich würde zuletzt interessieren, wie man sehen kann,

welche USE flags für welches programm bentuzt wurden.

im worldfile sieht man nur die programm kategorien+namen,

im package.use stehen nur die use flags, die man benutzen will,

aber woher weis ich welche use flags ein schon installiertes programm

aktiv nutzt, weil ich es zum beispiel bei emerge -e system vergessen habe ?

qpkg -I -v listet irgendwie dasselbe wie das worldfile...

ich bräuchte sowas wie emerge -pv <installiertes-packet>.

wo man use flags einzeln rauslesen kann...

----------

## firefly

du kannst wie folgt pakte neu installieren, deren USE-Flags sich verändert haben:

```
emerge -v --newuse world
```

gruß

firefly

----------

## tobiasbeil

 *firefly wrote:*   

> du kannst wie folgt pakte neu installieren, deren USE-Flags sich verändert haben:
> 
> ```
> emerge -v --newuse world
> ```
> ...

 

und mit emerge --version kann ich mir die versionsnummer anzeigen lassen.

und nun ?

was hat das mit meiner frage zu tun ???  :Shocked:   :Rolling Eyes:   :Rolling Eyes:   :Rolling Eyes: 

----------

## firefly

ähm ein 

```
emerge -e system
```

 bzw. 

```
emerge -e world
```

übersetzt alle installierten Pakete neu.

bei emerge -e system, werden halt nur die pakete neu übersetzt, die zum system-profile gehören.

bei emerge -e world werden alle pakete, samt abhängigkeiten neu übersetzt.

gruß

firefly

----------

## tobiasbeil

ok, nochmal ganz langsam:

ich finde was du gesagt hast ist richtig und auch echt gut.

ich wünschte mir nur du könntest lesen,

denn dann würde deine zugegeben korrekter beitrag auch einen sinn und bezug haben.

Gruss.

:rofl:

----------

## slick

 *tobiasbeil wrote:*   

> Mich würde zuletzt interessieren, wie man sehen kann,
> 
> welche USE flags für welches programm bentuzt wurden.

 

Willst Du es nur wissen oder in einem Script verarbeiten?

Um es zu wissen siehst Du es doch bei einem emerge -pvN world, die die dann grün (mit * sind) waren vorher anders. d.h. wenn z.B. bei emerge -pv net-fs/samba da steht +doc* heißt das das es vorher mit dem Useflag -doc installiert wurde und eine neues emergen des Paketes dieses mit doc installieren würde.

Umgekehrt:

Steht jetzt ein -doc* heißt das das es vorher mit dem Useflag doc installiert wurde und jetzt beim erneuten emerge mit -doc installiert würde.

----------

## tobiasbeil

d.h. also die richtige antwort auf meine frage wäre:

man kann es nciht direkt herausfinden.

nur als "workaround" mit dem angetäuschten emerge --newuse -v (-p).

ok. jetzt verstehen wir uns. ich dachte ihr wollt mich jetzt alles neukompilieren lassen....   :Razz: 

EDIT:

das ist trotzdem eine ziemlich schlechte lösung, schliesslich können sich die use flags ja mehrmals ändern,

aber wollte ja wissen mit welchen useflags die programme installiert wurden (verangenheit).

wenn ich meine use flags mal so einstell und dann mal so, kommen auch verschiedene änderungen hervor (-+bla*),

das bringt mich nicht weiter und ich kann nie wissen wie genau jetzt ein packet gemerged wurde...

aber da muss es doch so ne art log geben...., oder nicht ?

----------

## firefly

noe wollten wir nicht  :Wink: 

ich hatte dich so verstanden, das du alle pakete neuübersetzen wolltest, deren use-flags sich verändert haben oder ??

und das kannst du mit dem befehl

emerge --newuse -uD world machen  :Wink: 

gruß

firefly

firefly

----------

## x1jmp

suchst du danach?

```
$ emerge -pve system
```

d.h. das emerge zeigt dir alle Pakete mit ihren USE-Flags.

----------

## tobiasbeil

 *x1jmp wrote:*   

> suchst du danach?
> 
> ```
> $ emerge -pve system
> ```
> ...

 

hmm, kann ich nicht abschätzen,

kann es sein, dass er mir dann die default use flags anzeigt ??

oder sind das dann exakt ie use flags + - wie sie verwendet wurden

wärend der installation ??

----------

## slick

 *tobiasbeil wrote:*   

> wenn ich meine use flags mal so einstell und dann mal so, kommen auch verschiedene änderungen hervor (-+bla*),
> 
> das bringt mich nicht weiter und ich kann nie wissen wie genau jetzt ein packet gemerged wurde...

 

Also so langsam versteh ich Dein Problem nicht mehr.

Wenn Du öfters mal die Useflags änderst solltest Du dringend die Pakete die diese Änderungen betreffen mit emerge --newuse -uD world neu übersetzen, ansonsten kann es sein das Du Dir sehr schnell Dein System zerschießt. Und warum willst Du jetzt wissen mit welchen Useflags Du das Paket X vor Y Monaten installiert hattest? Braucht man auch nicht wissen behaupte ich mal. Kann das nicht nachvollziehen. 

Wenn Du dennoch ein solches "logfile" haben möchtest mach doch vor und nach jeder Änderung der Useflags / Update des Sytems folgendes:

```
date >> useflag.log ; emerge info | grep USE >> useflag.log ; emerge -pvN world >> useflag.log
```

Da kannst Du selbst nach Jahren noch nachvollziehen wie das Paket mal installiert war  :Wink: 

----------

## tobiasbeil

naja ich bin ja zugegebenermassen kein gentoo-crack, noch nciht,

aber mich stört zumbeispiel bei jeder stage1 installation der "/usr/portage/scripts/bootstrap.sh"-schritt,

aus dem simplen und einfachen grund, als dass ich keine kontrolle habe was genau da wie gemerged wird.

und ich wollte eigentlich alles "von anfang an" mit mienen vorstellungen mergen,

statt wie bisher, einfach bootstrap laufen lassen, und hinterher die persönlichen USE flags und einstellungen mitzugeben.

klingt komisch,

ist aber so.

EDIT:

du machst ja auch keine stage3 installation nur weils schnell geht,

und änderst dann alles extra um wie du wilst mit emerge -bDeNuq world, oder ?

EIDT2:

wobei das natürlich möglich ist....

----------

## slick

 *tobiasbeil wrote:*   

> statt wie bisher, einfach bootstrap laufen lassen, und hinterher die persönlichen USE flags und einstellungen mitzugeben.

 

Beim bootstrap werden die Useflags in /etc/make.conf beachtet, es gibt nur bestimmte Useflags die nur während des bootstraps benutzt werden, z.B. bootstrap, und später nicht mehr benötigt werden. Ich mache auch grundsätzlich stage1, jedoch passe ich vor dem bootstrap meine Useflags an.

----------

## tobiasbeil

 *slick wrote:*   

>  *tobiasbeil wrote:*   statt wie bisher, einfach bootstrap laufen lassen, und hinterher die persönlichen USE flags und einstellungen mitzugeben. 
> 
> Beim bootstrap werden die Useflags in /etc/make.conf beachtet, es gibt nur bestimmte Useflags die nur während des bootstraps benutzt werden, z.B. bootstrap, und später nicht mehr benötigt werden. Ich mache auch grundsätzlich stage1, jedoch passe ich vor dem bootstrap meine Useflags an.

 

ah, siehste, man lernt nie aus.

find ich ne zumutung dass man das alles in den foren mühsam lernen muss.

ich merke so langsam wie mächtig portage eigentlich ist, da sind die handbücher

aus der gnetoo doku ja kindergarten, da hätte ruhig was präziseres her kenna....

 :Confused: 

----------

## slick

 *tobiasbeil wrote:*   

> find ich ne zumutung dass man das alles in den foren mühsam lernen muss.
> 
> ich merke so langsam wie mächtig portage eigentlich ist, da sind die handbücher
> 
> aus der gnetoo doku ja kindergarten, da hätte ruhig was präziseres her kenna....

 

Nur so wirst Du doch zum richtigen Freak  :Wink: , Ok Spaß beiseite, wenn man sich tiefer mit der Materie auseinander setzen will muß man sich natürlich auf verschiedenen Wegen das Wissen selbst erarbeiten, es kann schlecht alles zu 100% mit Beispielen dokumentiert sein, zum einem weil es immer verschiedene Wege gibt das Ziel zu erreichen, andererseits würde eine solche Doku den Neuling total überfordern. 

Also immer schön im Forum mitlesen (ich denke dieser Thread wird auch bestimmt einem "heimlichen" Leser weitergeholfen haben  :Wink: ) und bleib dran, viel Spaß noch mit Gentoo.  :Wink: 

PS: Natürlich kannst Du ja, wenn Du Dir sicher bist, auch das Dokumentations-Team unterstützen und alles noch besser machen.  :Wink: 

----------

## Moartel

Einen kleinen (aber nicht zu verachtenden) Unterschied gibt es meines Wissens nach schon zwischen emerge bla oder emerge system und dem manuellen mergen aller einzelnen Pakete inkl. Abhängigkeiten:

Wenn du z.b. Firefox installierst, werden eine Menge Abhängigkeiten mitinstalliert. Solltest du eines Tages Firefox unmergen und die Abhängigkeiten weghaben wollen, einfach emerge --depclean und die Abhängigkeiten sind weg. Falls du aber jede Abhängigkeit von Hand emerget hast, musst du alle von Hand unmergen, weil depclean nur Pakete unmerget, die als Abhängigkeit und nicht explizit mit emerge bla installiert wurden.

----------

## tobiasbeil

also ich hab jetzt alles soweit wie ich es wollte,

jeodch habe ich wärend der installation einen offensichtlich wichtigen

schritt übersehen/-sprungen, den ich nach der inst. nachgeholt habe, nämlich:

# CONFIG_PROTECT="-*" emerge baselayout

leider weis ich nicht wie "schlimm" das jetzt war und was für auswirkungen das hat,

jedoch ist mir schon was negativ aufgefallen, nämlich die ausgabe von emerge sync:

```
gentoo ~ # emerge --sync --quiet

 * IMPORTANT: 9 config files in /etc need updating.

 * Type emerge --help config to learn how to update config files.

gentoo ~ #
```

die erzählt was von 9 config dateien , die upgedated werden müssen.

emerge --help config gibt irgendeine sehr allgeimeine ausgabe aus.

wie biegt man diesen fehler wieder gerade ??

----------

## chrib

Mittels etc-update oder alternativ dispatch-conf.

----------

## Roller

Das ist kein Fehler. Diese Ausgabe bedeutet, dass du deine config-Files update sollst, genauso wie es da steht. 

Wenn du ein Update machst, kommen neue Versionen bestimmter Pakete auf dein system. diese neuen Versionen bringen neue Funktionen mit, die du in den config-Files konfigurieren kannst. 

Das amchst du mit etc-update oder dispatch-conf. Du solltest aber aufpassen, da man sich bei diesem Schritt viel Ärger einhandeln kann. Das gilt allerdings auch, wenn du die Dateien  nicht aktualisierst.

Hier erfährst du mehr über das Thema: http://de.gentoo-wiki.com/Etc-update

Auf dieser Seit gibt es viele interressante Tutorials, Tips usw. die du dir anschauen solltest.

----------

## tobiasbeil

 *chrib wrote:*   

> Mittels etc-update oder alternativ dispatch-conf.

 

aha, und das reicht ?

was passiert da überhaupt ?

EDIT:

etc-update hat sich erledigt !

----------

## mr_elch

Was dispatch-conf macht ist recht gut im Handbuch und im Wiki beschrieben: http://www.gentoo.de/doc/de/handbook/handbook-x86.xml?part=3&chap=4#doc_chap2

http://gentoo-wiki.com/TIP_dispatch-conf

----------

## tobiasbeil

der ist grad mit dem mergen fertig und habe etc-update nun ausgeführt...

```
gentoo ~ # etc-update

Scanning Configuration files...

Automerging trivial changes in: .bash_logout

Automerging trivial changes in: .bash_profile

Automerging trivial changes in: bash_logout

Automerging trivial changes in: rc.conf

The following is the list of files which need updating, each

configuration file is followed by a list of possible replacement files.

1) /etc/skel/.bashrc

/etc/skel/._cfg0000_.bashrc

2) /etc/DIR_COLORS

/etc/._cfg0000_DIR_COLORS

3) /etc/bash/bashrc

/etc/bash/._cfg0000_bashrc

4) /etc/inittab

/etc/._cfg0000_inittab

5) /etc/locales.build

/etc/._cfg0000_locales.build

Please select a file to edit by entering the corresponding number.

              (don't use -3 or -5 if you're unsure what to do)

              (-1 to exit) (-3 to auto merge all remaining files)

                           (-5 to auto-merge AND not use 'mv -i'):
```

huch ??? was muss ich denn machen ? 

einfach "-3" wählen und ihn machen lassen ?

oder kann es sein das dabei was kaputt geht ?

soll ich lieber 5 nehmen ?

ka.

----------

## slick

Wirklich hier http://de.gentoo-wiki.com/Etc-update, wie oben schon empfohlen, gelesen?

----------

## tobiasbeil

tja wenn ich -1 drücke wird soviel ich weis alles beibehalten, wozu also der hinweis

ich soll meine configs updaten, andererseits kann ich ja nicht alles von hand ändern

geschweige denn vom blossen hingucken wissen, ob das so übernommen werden soll.

also ich drücke einfach mal -1 und hoffe das passt scho...

----------

## SinoTech

 *tobiasbeil wrote:*   

> tja wenn ich -1 drücke wird soviel ich weis alles beibehalten, wozu also der hinweis
> 
> ich soll meine configs updaten, andererseits kann ich ja nicht alles von hand ändern
> 
> geschweige denn vom blossen hingucken wissen, ob das so übernommen werden soll.
> ...

 

Also in der Regel kannst du config files, an denen du nichts geändert hast, ohne Bedenken mit neueren Versionen überschreiben.

Bei config Dateien bei denen du selbst Hand angelegt hast (Bsp.: "/etc/fstab", ...) solltest du dir ansehen was in der neueren Version geändert wurde und dann selbst entscheiden ob die alte ersetzt wirde oder nicht.

Mfg

Sino

----------

