ComputerBase
Aktuelles

[gentoo] wie haltet Ihr Euer gentoo aktuell?

emerge -u world, machen wir immer in der firma da dann iirc die ganzen packages aktualliesiert werden
 
naja, der sinn der beiden befehlen ist auch etwas anderes.

Code: 
emerge -u system
das updated nur die "system" packete, sprich die packete, welche nach einer stage3 installation vorhanden sind. das sind u.a. gcc, glibc, python, binutils, gettext, sed, nano, grep, ...

Code: 
emerge -u world
dieser befehl überprüft zusätzlich noch die packete und deren abhängigkeiten, die im world-file (/var/cache/edb/world) eingetragen sind. dort werden normalerweise alle packete automatisch eingetragen, die mit dem direkten befehl "emerge xxx" installiert werden.

ganto
 
Ich les erstmal Erfahrungsberichte von anderen, bevor ich mir den neuen $WAS_WEISS_ICH_SERVER installier und der nacher nicht geht. Ansonsten manuell oder emerge -u world / system.

mfg
 
mir gehts da in erster Linie um Sicherheitsupdates. Auch wenn ich noch nie irgendeinen "Einbruch" oder "Wurm" hatte - ich will es auch nicht dazu kommen lassen ;)
Und ich habe auch keine Lust, täglich irgendwelche Sicherheitsnews zu lesen. Gerade weil bestimmte Libs oder sonstwas mir vom Namen her nichts sagen.
 
server schrieb:
Ich les erstmal Erfahrungsberichte von anderen, bevor ich mir den neuen $WAS_WEISS_ICH_SERVER installier und der nacher nicht geht. Ansonsten manuell oder emerge -u world / system.

mfg
Zum Vergrößern anklicken....
naja, solange man bei den x86 packeten bleibt und nicht ~x86, dann kann man die updates sorglos installieren. ich hatte auf meinen beiden systemen noch nie probleme nach den updates. man sollte einfach die configs auch gewissenvoll anpassen (# etc-update).

ganto
 
Ganto schrieb:
naja, solange man bei den x86 packeten bleibt und nicht ~x86, dann kann man die updates sorglos installieren.
Zum Vergrößern anklicken....
Ich spiele gerade per "~x86" K3B ein (45 Pakete inkl. gcc und Kernel 2.4.22!?).
Wenn ich jetzt emerge -u world mache, heißt das dann, daß meine Pakete downgegraded werden? Sollte ich jetzt nur noch -U (großes U) machen?
 
machst du es per "ACCEPT_KEYWORDS="~x86" emerge foo"? Wenn ja solltest du damit aufhören. Du solltest eher in /etc/portage/package.keywords das Packet und ~x86 eintragen. Dann hast du auch hinterher nicht das Prob, dass Portage alles downgraden will.

Wenn du in deiner make.conf sowieso ACCEPT_KEYWORDS="~x86" stehen hast, ist das egal. Dann wirds sowieso immer dieses Keyword genommen.
 
ich würde dir mal die dokumentation von portage ans herz legen. -> http://www.gentoo.de/main/de/portage-2.0.50.xml

wenn du ein packet mit ~x86 installierst, dann wird das bei einem emerge -u world wieder zum x86 downgegradet. damit das nicht passiert, kannst du in der datei /etc/portage/package.keywords das entsprechende packet mit dem keyword, mit welchem du es installiert haben willst angeben (bei dir z.b. "app-cdr/k3b ~x86"). danach wird immer das testinpacket von k3b installiert resp. beibehalten.

ganto

/edit: och, da war noch jemand ein müh schneller :D
 
Erstmal vielen Dank an Hirion und Ganto.
Prinzipiell habt Ihr beide Recht.
Im Gentoo-Handbuch unter dem Punkt Portage & Software steht:
In bestimmten Fällen kann ein Update auch ein Downgrade (das heißt eine ältere Version ersetzt eine neuere) bedeuten. Falls Sie nicht möchten, dass so etwas passiert, können Sie die --upgradeonly Option (oder kurz -U) benutzen:

Code Listing 30: Upgraden Ihres gesamten Systems

# emerge --update --upgradeonly world

Demnach muß ich also vorerst mit
emerge -u -U world
leben. Aber das ist auch verschmerzbar. Ich könnte natürlich auch wieder downgraden, aber das ist mir zu unsicher, solange mein System stabil ist.
Sorgen machen mir nur die Unmengen an wesentlichen Systemkomponenten, die neu installiert wurden - und das alles nur für K3B.
 
Bald wird aber wahrscheinlich die --upgradeonly/-U Option abgeschafft werden, weil es dafür eben /etc/portage/* gibt.

Code: 
hirion dark # emerge -U

*** Warning: --upgradeonly is a deprecated option in portage-2.0.51_rc1
***          and will likely be removed in a future version.

Es gab auch mal nen Artikel auf forums.gentoo.org warum man diese Option nicht mehr benutzen sollte. Vielleicht finde ich den ja noch oder du findest den.

Warum sollte das eigentlich unsicher sein? ;)
Wenn in einem Packet kritische Sicherheitslücken entdeckt werden, hat das gefixte Packet meistens das Keyword x86 und nicht ~x86.
 
Gut, bei kritischen Sicherheitslücken. Aber bei K3B gibts schon ebuilds bis Version 17. Aber 12 ist noch stable. Und das, trotz eines seit langem bekannten Problem.

Aber daß ich jetzt wieder downgraden muß... :heul:

Naja. Versuch macht kluch, wie der Holsteiner sagt. Hab meine Lektion gelernt. Kann ich jetzt einfach wieder emerge -u world machen, und dann ist mein System wieder in dem Ursprungszustand? (also vor der Geschichte mit ~x86 für K3B?)
 
Du musst ja nicht downgraden ;)
Führ einfach
Code: 
echo "app-cdr/k3b ~x86" >> /etc/portage/package.keywords
aus und danach wird k3b nicht mehr gedowngradet.

Das System wird aber mit einem "emerge -u world" nicht in den Zustand davor gesetzt. Wahrscheinlich wurden irgendwelche neuen Packete installiert, etc. Die musst du natürlich unemergen.

Wie hast du eigentlich k3b emergt, dass du soviel neue Packete installieren musstest?

Falls du immer nur die neusten Packete haben willst, kannst du ja gleich ACCEPT_KEYWORDS="~x86" in die make.conf eintragen. Kann aber passieren, dass mal nen nicht sehr stabiles Packet mitinstalliert wird, aber das ist eher selten. Würde es den meisten aber trozdem nicht empfehlen, auch wenn ich selber ~amd64 benutze.

PS: Wat nen Denglisch :D
 
Zuletzt bearbeitet:
Naja. Ich mache alle 2-3 tage ein emerge sync. Dann ein emerge -p -u world, um zu sehen, ob es was interessantes oder wichtiges gibt (von dem ich gelesen habe).
Je nachdem mache ich dann ein emerge -u world
Um jetzt K3B in Version 0.11.17 zu bekommen (mit dem behobenen Fehler für DVD), hab ich einmalig und erstmalig
ACCEPT_KEYWORDS="~x86" emerge k3b
gemacht. Vorher also nur "x86" = stable. Kein Testing.
Wenn Du ein rein stabiles System hast, kannst Du ja mal zur Probe das ausprobieren (mit -p). :(
 
wenn überhaupt mache ich ein emerge sync && emerge -up world um zu sehen was es neues gibt. wenn es sachen sind die mich interessieren oder wenn ne menge angefallen ist mache ich dann ein emerge -u world.

werde die tage aber wieder das ganze system platt machen, da ich jetzt ein march=athlon-xp system habe aber nen athlon64 drin. das hat zur folge dass sogar das suse9.1-64bit system schneller war als jetzt gentoo. wenn also suse unter 64bit schon schneller ist als gentoo, wie schnell ist dann gentoo64bit? :cool_alt: ich hoffe nur dass es irgendwann mal klappt.

PS: @tux
1. ich hab das problem mit k3b auch - werde aber auf die stable warten da es bei mir nicht eilt
2. wer faul ist macht anstatt emerge -p -u world einfach emerge -up world (wenn man so faul ist wie ich findet man immer irgendwelche abkürzungen ;) )
 
Wie ich schon gesagt habe. Ich benutze ~amd64 also kein stabiles System ;)

Du kannst ja mal einfach nen emerge -u world machen. Alles was dann als ~x86 installiert wurde, wird dann durch die letzte x86 Version erstetzt und um das bei K3B zu verhindern, musst du dann eben wie oben beschrieben den Befehl erst einmal ausführen.
 
Äh, nur mal so. Das kommt bei mir raus, wenn ich emerge -up world eingebe... btw: k3b habe ich schon als ~ maskiert. Mit dem Befehl von Hirion.

These are the packages that I would merge, in order:

Calculating world dependencies ...done!
[blocks B ] sys-apps/sysvinit (from pkg sys-apps/baselayout-1.9.4-r3)

[ebuild UD] app-shells/bash-2.05b-r9 [3.0-r5]
[ebuild UD] sys-devel/gettext-0.12.1 [0.12.1-r1]
[ebuild UD] sys-apps/texinfo-4.6 [4.7-r1]
[ebuild UD] sys-apps/groff-1.18.1-r4 [1.19.1-r1]
[ebuild UD] sys-libs/db-1.85-r1 [1.85-r2]
[ebuild UD] sys-libs/gdbm-1.8.0-r5 [1.8.3-r1]
[ebuild UD] sys-devel/libperl-5.8.4-r1 [5.8.5-r1]
[ebuild UD] dev-lang/perl-5.8.4-r1 [5.8.5]
[ebuild UD] sys-apps/util-linux-2.12-r4 [2.12b]
[ebuild UD] sys-kernel/linux-headers-2.4.21-r1 [2.4.22]
[ebuild UD] sys-apps/baselayout-1.9.4-r3 [1.10.4]
[ebuild UD] sys-devel/binutils-2.14.90.0.8-r1 [2.15.90.0.1.1-r3]
[ebuild UD] sys-libs/glibc-2.3.3.20040420-r1 [2.3.4.20040808]
[ebuild UD] sys-apps/sed-4.0.9 [4.1.2]
[ebuild UD] sys-libs/readline-4.3-r4 [5.0]
[ebuild UD] dev-libs/expat-1.95.7 [1.95.8]
[ebuild UD] dev-lang/python-2.3.3-r1 [2.3.4]
[ebuild UD] sys-apps/portage-2.0.50-r11 [2.0.51_rc4]
*** Portage will stop merging at this point and reload itself,
recalculate dependencies, and complete the merge.
[ebuild UD] sys-libs/cracklib-2.7-r8 [2.7-r10]
[ebuild UD] sys-libs/pam-0.77 [0.77-r1]
[ebuild UD] media-libs/tiff-3.5.7-r1 [3.6.1-r1]
[ebuild UD] net-print/cups-1.1.20-r2 [1.1.21]
[ebuild UD] sys-fs/e2fsprogs-1.35 [1.35-r1]
[ebuild UD] x11-misc/ttmkfdir-3.0.9-r1 [3.0.9-r2]
[ebuild UD] media-libs/fontconfig-2.2.2 [2.2.3]
[ebuild UD] x11-base/opengl-update-1.7.2 [1.8.1-r1]
[ebuild UD] x11-base/xorg-x11-6.7.0-r2 [6.8.0-r1]
[ebuild UD] x11-terms/xterm-191 [196]


So. Und nun weiß ich auch genau, was da so alles solange gedauert hat. Kann mir mal einer verraten, was die 2.4'er-Kernel Header da sollen? Ich habe 2.6.7!

uname -a
Linux gentux73 2.6.7 #4 SMP Wed Sep 8 06:22:14 CEST 2004 i686 Intel(R) Pentium(R) 4 CPU 2.60GHz GenuineIntel GNU/Linux

Aber das ist eine andere Geschichte.

Vom Prinzip her, bräuchte ich doch eigentlich nur noch zu warten, bis die "~Pakete" stable sind. Die Liste mit den [UD]'e müßte ja von Woche zu Woche geringer werden, oder?
 
tux73 schrieb:
Äh, nur mal so. Das kommt bei mir raus, wenn ich emerge -up world eingebe... btw: k3b habe ich schon als ~ maskiert. Mit dem Befehl von Hirion.

These are the packages that I would merge, in order:

Calculating world dependencies ...done!
[blocks B ] sys-apps/sysvinit (from pkg sys-apps/baselayout-1.9.4-r3)

[ebuild UD] app-shells/bash-2.05b-r9 [3.0-r5]
[ebuild UD] sys-devel/gettext-0.12.1 [0.12.1-r1]
[ebuild UD] sys-apps/texinfo-4.6 [4.7-r1]
[ebuild UD] sys-apps/groff-1.18.1-r4 [1.19.1-r1]
[ebuild UD] sys-libs/db-1.85-r1 [1.85-r2]
[ebuild UD] sys-libs/gdbm-1.8.0-r5 [1.8.3-r1]
[ebuild UD] sys-devel/libperl-5.8.4-r1 [5.8.5-r1]
[ebuild UD] dev-lang/perl-5.8.4-r1 [5.8.5]
[ebuild UD] sys-apps/util-linux-2.12-r4 [2.12b]
[ebuild UD] sys-kernel/linux-headers-2.4.21-r1 [2.4.22]
[ebuild UD] sys-apps/baselayout-1.9.4-r3 [1.10.4]
[ebuild UD] sys-devel/binutils-2.14.90.0.8-r1 [2.15.90.0.1.1-r3]
[ebuild UD] sys-libs/glibc-2.3.3.20040420-r1 [2.3.4.20040808]
[ebuild UD] sys-apps/sed-4.0.9 [4.1.2]
[ebuild UD] sys-libs/readline-4.3-r4 [5.0]
[ebuild UD] dev-libs/expat-1.95.7 [1.95.8]
[ebuild UD] dev-lang/python-2.3.3-r1 [2.3.4]
[ebuild UD] sys-apps/portage-2.0.50-r11 [2.0.51_rc4]
*** Portage will stop merging at this point and reload itself,
recalculate dependencies, and complete the merge.
[ebuild UD] sys-libs/cracklib-2.7-r8 [2.7-r10]
[ebuild UD] sys-libs/pam-0.77 [0.77-r1]
[ebuild UD] media-libs/tiff-3.5.7-r1 [3.6.1-r1]
[ebuild UD] net-print/cups-1.1.20-r2 [1.1.21]
[ebuild UD] sys-fs/e2fsprogs-1.35 [1.35-r1]
[ebuild UD] x11-misc/ttmkfdir-3.0.9-r1 [3.0.9-r2]
[ebuild UD] media-libs/fontconfig-2.2.2 [2.2.3]
[ebuild UD] x11-base/opengl-update-1.7.2 [1.8.1-r1]
[ebuild UD] x11-base/xorg-x11-6.7.0-r2 [6.8.0-r1]
[ebuild UD] x11-terms/xterm-191 [196]


So. Und nun weiß ich auch genau, was da so alles solange gedauert hat. Kann mir mal einer verraten, was die 2.4'er-Kernel Header da sollen? Ich habe 2.6.7!

uname -a
Linux gentux73 2.6.7 #4 SMP Wed Sep 8 06:22:14 CEST 2004 i686 Intel(R) Pentium(R) 4 CPU 2.60GHz GenuineIntel GNU/Linux

Aber das ist eine andere Geschichte.

Vom Prinzip her, bräuchte ich doch eigentlich nur noch zu warten, bis die "~Pakete" stable sind. Die Liste mit den [UD]'e müßte ja von Woche zu Woche geringer werden, oder?
Zum Vergrößern anklicken....

wieso willste denn das ganze system unstable bringen? reicht doch wenn de nur k3b unstable bringst.
und die 2.4 kernel-header braucht man eigenlich net mehr, bei mir sind nur die 2.6er drauf.
 
Das was man bei dir sieht, ist ein Grund, warum man kein --upgradeonly benutzen sollte ;)

Die 2.4 Header hast du zum kompilieren von glibc und vielleicht nen paar anderen Programmen benutzt. Du könntest die neueren linux26-headers emergen und damit dann die glibc neu kompilieren. Das hätte dann den Vorteil (falls du nptl in die USE Flags hinzufügst), dass die glibc dann bei dir NPTL unterstützt. Nen paar Infos darüber kannst du dir hier holen: http://de.wikipedia.org/wiki/NPTL

Um den Blocker bei dir wegzubekommen, kannst du versuchen sysvinit zu unemergen und danach sofort baselayout emergen, aber ich habe kA was passiert, wenn bei dir init für eine kurze Zeit fehlt. Deswegen: Awendung auf eigene Gefahr. Falls es klappt, kannst du dann nen emerge -u --world machen.

Zur eigentlich Frage: Klar kannst du solange warten, aber das kann nen bisschen dauern. ;)

EDIT: Gerade gesehen. THX für das gute Karma :)
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.

Ähnliche Themen

M
in /var/db/repos/gentoo steht unter LICENSES: NVIDIA-2025 (blockiert)
Antworten
4
Aufrufe
659
undefined
U
M
gentoo-unstable update Unterbrechung
2
Antworten
33
Aufrufe
2.213
ManBla
M
Linuxfreakgraz
KI Reperatur und Wartungsassistent in der kommenden Ubuntu Version 26.04 LTS geplannt. Was haltet Ihr davon?
Antworten
9
Aufrufe
932
@mo
@
Goatman
XMG EVO 15 (E25) mit AMD Ryzen AI9 HX 370 Was haltet Ihr vom aktuellen 96hours Deal? 1464 Euro
Antworten
4
Aufrufe
728
Goatman
Goatman
M
  • Gesperrt
Welches PC‑Gehäuse ist euer Favorit / Wunschmodell & warum? (Und was habt ihr aktuell?)
Antworten
12
Aufrufe
1.273
burnout150
burnout150

Passend zum Thema

Zurück
Oben

Willkommen auf ComputerBase!

Mit Werbung weiterlesen

Besuche ComputerBase wie gewohnt mit Werbung und Tracking. Die Zustimmung ist jederzeit widerrufbar.

Details im Privacy Center und in der Liste unserer Partner. Ein Widerruf ist möglich in der Datenschutzerklärung.

… oder ComputerBase Pro bestellen

Nutze ComputerBase ohne Werbebanner, Video-Ads und Werbetracking schon für 4 €/Monat oder 36 €/Jahr.

Mehr zu ComputerBase Pro

Bereits Pro-Nutzer? Hier anmelden.

Tracking: Wir und unsere 187 Partner verarbeiten personenbezogene Daten, indem wir mit auf Ihrem Gerät gespeicherten Informationen (z. B. eindeutige Kennungen in Cookies) ein Nutzungsprofil erstellen, um z. B. Anzeigen zu personalisieren. Verarbeitungszwecke: Genaue Standortdaten und Abfrage von Geräteeigenschaften zur Identifikation, Informationen auf einem Gerät speichern und/oder abrufen, Personalisierte Anzeigen und Inhalte, Anzeigen- und Inhaltsmessungen, Erkenntnisse über Zielgruppen und Produktentwicklungen.

Impressum Kontakt Datenschutz