binpkg - neue Erfahrung

[ManfredB]

Fazit:

Meine auf dem PC erstellten binpkgs (kde-plasma und kde-apps) habe ich auf die USB-Platte kopiert,
dann die USB-HD ans Notebook angeschlossen,
gentoo gestartet und dann in 2 Schritten:
1. emerge --ask -k kde-plasma/plasma-meta
2. emerge --ask -k kde-apps/kde-apps-meta.

Von ganz wenigen Ausnahmen abgesehen, werden die überwiegende Zahl von binpkgs übernommen
und installiert.

Auf diese Weise erspare ich dem Notebook eine Überlastung und freue mich,
daß ich endlich auch da Gentoo nutzen kann.

Einen schönen Ostermontag an alle.

Gruß
Manfred

[ManfredB]

Und diese Zeilen schreibe ich vom plasma-Desktop.

Es hat also geklappt und ich bin sehr zufrieden damit.

Gruß
Manfred

[Max Steel]

Dyas klingt sehr nach Kühlungsproblemen des Laptops. Ich hab jetzt heute leider nicht die Zeit Backlog zu lesen und meine Erinnerungen sind verdunkelt (Osterwochenende undso)
Aber hattest du das GErät mal geöffnet und die Lüfter ausgebaut? Hängt da evtl viel Staub/KAtze/Hund/Kaninchen/sonstirgendeinhaariges/schuppigesTieraußenkleid drin?
Weil eigentlich sollte ein Gerät zumindest ohne übertaktung nicht zu heiß laufen... solange es kein Macbook ist. Aber ansonsten achten da alle Hersteller drauf... normalerweiße.
_________________
mfg
Steel
___________________

Heim-PC: AMD Ryzen 5950X, 64GB RAM, GTX 1080
Laptop: Intel Core i5-4300U, 16GB RAM, Intel Graphic
Arbeit-PC: Intel i5-1145G7, 16GB RAM, Intel Iris Xe Graphic (leider WSL2)

[ManfredB]

Die Öffnung dieses schon recht alten Notebooks traue ich mir nicht zu,
denn es könnte passieren, daß dabei etwas kaputt geht...

Solange ich dieses Lenovo noch nutzen kann, bin ich - was diesen Punkt angeht -
sehr zurückhaltend.

Wenn ich zB ArchLinux oder Mageia update, wird das Notebook nur leicht warm,
aber nicht heiss - will sagen: Diese Distributionen (neben Windows 10) nutze ich
hauptsächlich.

Gentoo war und ist ein Testfall im Zusammenhang mit den binpkgs.

Und so soll es auch bleiben.

Gruß
Manfred

[ManfredB]

Heute habe ich eine neue Erfahrung gemacht.

Eine Neuinstallation von Gentoo (ACCEPT_KEYWORDS="~amd64") habe ich durchgeführt.

Zuerst natürlich wie immer die Basis-Installation.
Nach reboot dieses Systems lande ich auf Konsole, logge mich als root ein.

In der /etc/portage/make.conf ist nun folgendes eingetragen:
FEATURES="buildpkg"

Da ich schon etliche binpkgs habe, nutze ich die natürlich, um den oft langen Prozess der Installation abzukürzen.

Und jetzt kommts:
Manchmal sind die binpkgs nicht mehr ganz aktuell, weil inzwischen wieder mal einige Updates gekommen sind.
Bei der Neuinstallation habe ich genau dieses Pakete genutzt und zB
emerge --ask -k kde-plasma/plasma-meta
eingegeben.
Die meisten binpkgs, die schon vorhanden sind, werden recht schnell installiert.
Aber dabei kommt es vor, daß das eine oder andere Paket neu ist.
Da buildpkg in der make.conf steht, werden diese Pakete zu binpkgs verwandelt und damit das gesamte vorhandene erweitert.

Vorteil dieses Verfahrens:
Ich brauche nun nicht mehr riesige Updates durchzuführen, sondern kann immer die aktualisierten binpkgs nutzen.

Daß das alle ohne Probleme läuft. hätte ich vor Monaten nicht geahnt.
Doch Versuche sind immer wieder wichtig und das ist nun das Ergebnis.

Ich trenne natürlich die Sparten
stable
amd64
systemd (wobei unter systemd auch amd64-Pakete genutzt werden)

Dazu habe ich mir auf einer HD Verzeichnisse angelegt, zB
kde-plasma-meta
mit den Unterverzeichnissen
distfiles
packages

So bekomme ich von jeder Gentoo-Installation inzwischen Pakete dazu,
auch wenn diese Installationen immer wieder binpkgs nutzen.

Es macht richtig Spaß, auf diese Weise den Distributionen auf die Spur zu kommen,
die auf gentoo basieren.

Gruß
Manfred

[ManfredB]

Hallo zusammen,

gestern habe ich einen neuen Versuch gestartet.

Grund: ich wollte einmal alle Pakete, die bei der Installation von Gentoo anfallen,
als binpkgs bekommen.

Daher habe ich schon am Anfang "FEATURES="buildpkg" in die make.conf eingetragen.
Um mit dem Platz klarzukommen, habe ich für /var 20 Gb zur Verfügung.

Ich lasse also alle binpkgs und distfiles im Verzeichnis liegen.
Erst, wenn alles einschl. kde-plasma-meta und kde-apps-meta und etliche von mir benötigte Pakete
zu Ende gebracht ist, werden diese auf die HD verschoben.

Auf diese Weise habe ich nun ein Gesamt-Paket von binpkgs, die ich für eine Neuinstallation
einsetzen kann.

Klar finden das einige verrückt, aber ich teste das Ganze nur, um meine Kenntnisse über
die Distributionen mit binpkgs zu erweitern.

Der Umfang des Gesamtpakets ist schon recht gewaltig, aber da ich genügend Speicher habe,
ist das kein Problem.

Gruß
Manfred

[ManfredB]

Hallo zusammen,

so langsam komme ich sehr gut zurecht mit den binpkgs.

Ich habe seit einiger Zeit ein neues Notebook Acer Aspire,
was von der Leistung her etwas stärker ist als das Lenovo.

Dort kann ich ohne weiteres auch akzeptieren, wenn neben den binpkgs mal
das eine oder andere Paket neu generiert wird.

distfiles sind nicht notwendig, wenn ich ein System per binpkgs aktualisieren will.

Außerdem habe ich festgestellt, daß die Riesendatei, die unter den binpkgs
liegt und alles zusammenfasst, was bisher passiert ist, auch nicht unbedingt
rüberkopiert werden muss in eine Neuinstallation.

Es reichen schlicht und einfach nur die binpkg-Verzeichnisse, in denen die Pakete
liegen. So ist das, was ich zuletzt geschrieben habe: die /var-Partition größer als 10 Gb zu machen,
vollkommen überflüssig, weil der Platz nach den neuen Erkenntnissen vollkommen ausreicht.

Heute habe ich zB meine systemd-Installation per binpkg aktualisiert.
Klar kommen da Pakete hinzu, die für das systemd-System benötigt werden,
aber die sind zB verglichen mit kde-plasma/plasma-meta oder kde-apps/kde-apps-meta
von der Zahl her so gering.

Aber ich freue mich sehr, daß meine Versuche immer wieder neue Einsichten und Erkenntnisse mit sich bringen.
So kann ich auf einfache Weise meine System aktuell halten.

Gruß
Manfred

[ManfredB]

Kleiner Überblick über eine binpkg-Installation von gentoo-stable


WIKI-Anleitung sollte in jedem Fall genutzt werden.

Voraussetzung: binpkgs sollten einmal komplett hergestellt worden sein,
das ist ein langer Prozess, aber er lohnt sich nach meiner Auffassung und Efahrung.

Sobald man in der chroot-Umgebung angekommen ist
und als erstes
emerge-webrsync
durchgeführt hat,
empfehle ich auf Anraten eines Mitglieds dieses Forums
emerge -av1 gnutls

Wenn dann noch
emerge –sync –quiet
folgt, kommen die in diesem Forum angesprochenen Probleme nicht mehr vor.

Es funktioniert also einwandfrei.

Nach Auswahl des Profils (bei mir ist es 23 desktop plasma)
kommt die Stelle, wo ein umfangreiches Update efolgt:
227 Pakete (so jedenfalls bei mir mit einer NVIDIA-Grafikkarte).

Hier habe ich die kompletten binpkgs in das binpks-Verzeichnis
unter /var/cache
kopiert.

Nun kommt der Befehl
emerge --ask --verbose --update --deep --newuse -k @world

Es fällt auf, daß gegenüber den Angaben im WIKI hier vor @world -k eingefügt ist.

Das dient dazu, den Prozess mit binpkgs auszuführen.

Von den 227 Paketen
sind 216 binpkgs
und 11 Original-Pakete
1 dev-libs/libpthread-stubs-0.4-r1::gentoo
2 acct-group/messagebus-0::gentoo
3 sys-libs/zlib-1.2.11-r2::gentoo
4 x11-libs/libXau-1.0.9::gentoo
5 x11-libs/libXdmcp-1.1.3::gentoo
6 x11-base/xcb-proto-1.13::gentoo
7 x11-libs/libxcb-1.13.1::gentoo
8 x11-libs/libX11-1.6.8::gentoo
9 x11-libs/libXext-1.3.4::gentoo
10 sys-apps/util-linux-2.33.2::gentoo
11 sys-apps/dbus-1.12.16::gentoo

Was ich besonders beachte:
Nach der Basis-Installation und dem Neustart des Systems
installiere ich die nvidia-drivers erneut, denn das binpkg dazu
taucht in /lib/modules nicht auf.
Erst danach sind sie dort zu finden.

Sollte in einer bereits bestehenden gentoo-Installation einmal - wie in diesen Tagen -
ein kernel-update erfolgen und man nach
eselect kernel list
noch
eselect kernel set 2 (der neue Kernel)
ausführt, ist die erneute Installation des
nvidia-drivers (als Original-Paket, nicht als binpkg)
dringend notwendig.

Inzwischen bin ich sogar doch noch einmal zurück zu den Original-Paketen gegangen,
und zwar - in der chroot-Umgebung - kernel und genkernel, denn die Installation
dieser Pakete dauert nicht so lange und ist nach meinem Empfinden besser als immer nur
die binpkgs zu nutzen.

Nach dem reboot also - die vorhandenen binpkgs bleiben im System -
beginne ich in zwei großen Stufen mit der weiteren Installation:
1. emerge --ask -k kde-plasma/plasma-meta kde-plasma/plasma-nm
214 Pakete
2. emerge --ask -k kde-apps/kde-apps-meta
275 Pakete
(manchmal auch nur
emerge --ask -k kde-apps/kdeadmin-meta kde-apps/kdegraphics-meta kde-apps/kdemultimedia-meta kde-apps/kdeutils-meta kdialog konsole kcalc kwrite krusader)

In der Folge sind es noch einzelne Pakete, die ich für meine Bedürfnisse benötige:
emerge --ask -k
firefox-bin
thunderbird-bin
phonon-gstreamer
alsa-tools
gutenprint
gparted
app-misc/mc
eix
gentoolkit
libreoffice
libreoffice-l10n

So habe ich nun in einem geringen Zeitaufwand ein komplettes System installiert,
was mich sehr an die auf gentoo basierenden Distributionen erinnert:
Sabayon
Redcore
ArchLinux
Calculate

Mit diesen Distributionen habe ich mich in der Vergangenheit und der Gegenwart intensiv beschäftigt.

Und heute kann ich sagen, daß ich bei gentoo soweit gekommen bin, Teile dieser genannten Distributionen nachgebildet zu haben.
Allerdings geht mein Interesse nicht dahin, eine installierbare gentoo-iso zu bauen.

Dazu müsste ich wahrscheinlich noch viel mehr in die Tiefe des Systems einsteigen,
doch das habe ich nicht mehr vor.

Gruß
Manfred

[ManfredB]

Interessant für mich:

Wenn ich ACCEPT_KEYWORDS="~amd64" nutze,
kommen beim Update in der chroot-Umgebung
376 packages (100 upgrades, 248 new, 7 in new slots, 21 reinstalls)

Das sind deutlich mehr als in der stable-Version.

Der Grund dafür ist mir nicht bekannt.

Gruß
Manfred

[ManfredB]

Bei der letzten amd64-Installation ist mir ein merkwürdiges Verhalten aufgefallen:

Nach dem in der chroot-Umgebung durchgeführten Update per binpkgs,
waren
ermerge @preserved-rebuild
erforderlich.
Nachdem ich das durchgeführt hatte,
kam dasselbe erneut.
Und danach wieder.

Aufgehört hat es erst, als ich das Programm, um das es darin ging,
ohne -k neu installiert habe: pam.

Das zeigt mir, daß es bei dem in der chroot-Umgebung durchgeführten Update
nicht ohne leichte Irrirtationen geht, vor allem, wenn binpkgs genutzt werden.

gcc-8.3.0 ist Standard. Bei der Nutzung von amd64 kommt gcc-9.2.0 dran.

Heute habe ich vor dem kompletten chroot-Update gcc-9.2.0 vorausinstalliert,
um zu verhindern, daß am Ende Pakete rebuild werden müssen auf gcc-8.3.0.
Ich bin sehr gespannt, wie das ausgeht, denn nun wird das gesamte Update
per gcc-9.2.0 konfiguriert.

Gruß
Manfred

P.S. das war doch ein Fehler, denn gcc-9.2.0 wurde erst installiert,
beim großen Update tauchten plötzlich rebuild-Pakete auf, 9.2.0 noch einmal.

ich habe das abgebrochen und bin wieder auf den Standardweg zurückgekehrt.

[ManfredB]

Mein Ergebnis:

Ich habe auf meinem Rechner zwei Gentoo-Installationen ohne user und nur als buildpkg-Distributionen:
Gentoo-stable
Gentoo amd64

Alle Updates der bestehenden Gentoo-Installationen hole ich mir als binpkgs von dort.

Das klingt sicher verrückt, aber ich habe so viel über gentoo inzwischen gelernt,
daß es mir wirklich Spaß macht.

Gruß
Manfred

[ManfredB]

Eine weitere Entwicklung:

Heute habe ich auf meinem Rechner eine komplette Neuinstallation von Gentoo amd64 durchgeführt,
und zwar komplett mit binpkgs (kleine Ausnahmen kommen immer wieder vor).

Was ich hier gerade schreibe, tue ich aus dem neuen System heraus,
welches ohne Probleme funktioniert.

Bei einer solchen Neuinstallation habe ich bisher die gefertigten binpkgs jedesmal aus dem Verzeichnis
auf einer anderen Festplatte herüberkopiert, was ich auf Dauer etwas nervig empfand.
Also habe ich zwei neue Partitionen erstellt, die eine für stable, die andere für amd64.

Diese Partitionen mit den Labels p_gam und p_gen kann ich nun in eine Neuinstallation einbinden,
in dem ich dort /mnt/gentoo/gen bzw. /mnt/gentoo/gam einrichte.

So greift das System immer direkt auf die Datenpakete zu und ich muß nichts mehr hin- und herkopieren.

Dafür muss ich in der /etc/portage/make.conf folgende Einträge ändern:

[ManfredB]

Und jetzt kommt der Hammer:

Ich bin schon lange auf der Suche nach einer Lösung, wie ich die /etc/fstab unter gentoo automatisch erstellen kann,
so wie es unter ArchLinux funktioniert.

Heute habe ich mir einmal die arch-install-scripts heruntergeladen und im /home-Verzeichnis per tar entpackt.

In dem da enstandenen Verzeichnis
/usr
sind zwei Unterverzeichnisse:
/bin
/share
Unter /bin liegen 3 Programme:
arch-chroot
genfstab
pacstrap

Das Programm genfstab habe ich unter Gentoo amd64 nach /usr/bin/ kopiert

Unter /share sind es 3 Verzeichnisse:
/bash-completion
/man
/zsh

Auch diese Verzeichnisse habe ich nach /usr/share kopiert.

Nun habe ich eine bestehende Gentoo-Installation gemountet:
mount -L p_gam_u3 /mnt/gentoo
mount -L p_gam_u3_usr /mnt/gentoo/usr
mount -L p_gam_u3_var /mnt/gentoo/var

Die unter /mnt/gentoo/etc liegende fstab habe ich vorsichtshalber gesichert.

Dann
genfstab -Lp /mnt/gentoo > /mnt/gentoo/etc/fstab

Und ihr werdet es vielleicht einfach nicht glauben (das ging mir zuvor auch so):
es hat geklappt, die /mnt/gentoo/etc/fstab sieht genau so aus wie die von ArchLinux aus erstellte fstab.

Nun kann ich mir den Umweg über ArchLinux sparen, wenn ich wieder einmal Gentoo installieren werde.

Dann nutze ich einfach die mit genfstab ausgestattete Gentoo-Installation und kann dann loslegen.

Gruß
Manfred

[Max Steel]

Du könntest auch das Overlay ROKO verwenden und die arch-install-scripts darüber installieren...

https://wiki.gentoo.org/wiki/Ebuild_repository
https://gpo.zugaina.org/dev-util/arch-install-scripts

Aber gleichzeitig weiß ich nicht ob es so gut ist dir schon die Overlay Möglichkeiten zu zeigen.


Zweischneidiges Schwert.
Sei gewarnt, zu viel oder das falsche Paket ist nicht gut und kann zu Instabilitäten. Komplikationen oder gar zu Datenverlusten führen. (das klang kurz wie ein Drogen-einwurf...)
_________________
mfg
Steel
___________________

Heim-PC: AMD Ryzen 5950X, 64GB RAM, GTX 1080
Laptop: Intel Core i5-4300U, 16GB RAM, Intel Graphic
Arbeit-PC: Intel i5-1145G7, 16GB RAM, Intel Iris Xe Graphic (leider WSL2)

[ManfredB]

Heute habe ich wieder einmal einen Test gemacht:

Auf meiner 2. SSD-Platte ist ziemlich am Anfang eine unstable-Version von Gentoo installiert.
Die stammt von Anfang Oktober 2019.

Dort war noch der Kernel 5.3.7 installiert.

Ich habe diese Partition (incl. /var und /usr und /gam) gemountet.
Was kaum jemand glauben mag: alles außer dem /home-Verzeichnis habe ich gelöscht.
/var - /usr - /gam natürlich nicht, sondern nur den Inhalt von /var und /usr.

Danach die neueste stage3-*.tar.xz heruntergeladen und auf dieser gemounteten Partition entpackt.

In der chroot-Umgebung bin ich genau nach dem AMD64-Handbuch vorgegangen.
Doch als das erste große Update mit über 350 Paketen anstand, habe ich in die Zeile vort @world
noch -k eingefügt, um kein so langes Update mit Original-Paketen zu erhalten.

Innerhalb kürzester Zeit war dieses Update durch.
Kernel und genkernel original
Auch die kleinen Zusatzpakete original, zB sysklogd mlocate cronie dhcpcd und schließlich noch grub:2.

Normalerweise ist nach
grub-mkconfig -o /boot/grub/grub.cfg
Ende der chroot-Umgebung.

Bei mir heute nicht:
emerge --ask -k kde-plasma/plasma-meta kde-plasma/plasma-nm
Danach die von mir ausgewählten Paket-Gruppen aus kde-apps/*

Alles, was sonst bereits außerhalb der chroot-Umgebung passiert,
zB rc-update add dbus boot
rc-update add consolekit default usw.

useradd -m -g users -s /bin/bash ~

Als ich nach allen erforderlichen Einstellungen aus der chroot-Umgebung ausgestiegen bin
(der grub.cfg-Eintrag ist bereits im Haupt-Bootloader eingetragen)
habe ich mein System, aus dem heraus ich diese Installation ausgeführt habe,
neu gestartet und die Neuinstallation gebootet.

Ich lande auf dem sddm-login-screen, gebe mein Passwort ein, komme zu dem bereits vorhandenen
Desktop.

Alles funktioniert eiwandfrei, was ich hier schreibe, kommt direkt aus dieser Neuinstallation.

Einfacher kann es gar nicht sein, gentoo zu installieren mit binpkgs.

Gruß
Manfred

Noch ein kleiner Nachtrag:
Auto-Login funktioniert bei mir auf dem PC nur mit der unstable-Version,
bei der stable-Version kommt immer wieder der login-screen.
Auf dem Notebook habe ich kaum Chancen mit auto-login.
Grafik-Karte auf PC: nvidia, auf Notebook intel

[ManfredB]

Hallo zusammen,

ich habe inzwischen eine neue Erfahrung gemacht.

Konflikte entstehen zB mit libXau und dazugehörigen Paketen.
Dort sehe ich, daß irgendetwas mit ABI 32 und ABI 64 nicht stimmt.

Daraufhin habe ich heute einmal in kernel-config nachgeschaut,
gesucht nach binary.
Dort habe ich gesehen, daß unter
Binary Emulations
CONFIG_IA32_EMULATIONS=y
CONFIG_X86_X32=y
CONFIG_COMPAT_32=y
steht.

Heißt das, daß binarypkg in Version 32 statt 64 kompiliert wird?

Ich habe das deaktiviert in der Hoffnung, daß die oben genannten Konflikte nicht mehr auftauchen.

Frage;
Sehe ich das richtig? Oder bin ich auf dem falschen Parkett gelandet?

Danke im voraus für Statements.

Gruß
Manfred

[ManfredB]

Ein weiterer Fortschritt:

Kurz gesagt: ich habe je eine buildpkg-Installation und eine binpkg-Installation.
Dazu habe ich - wie schon beschrieben - /var/cache und /var/db in einem Verzeichnis außerhalb.

In /etc/portage/repos.conf/gentoo.conf habe ich in der Zeile 5 location das Verzeichnis geändert:
für systemd steht dort am Anfang gsy
für unstable gam
für stable gen

Und in der /etc/portage/make.conf
PORTDIR
DISTDIR
PKGDIR
mit denselben Abkürzungen alle 3 Zeilen versehen.

Erfolg dieses Vorgehens:
Ich starte morgens zuerst die 3 buildpkg-Versionen und gehe so vor:
emerge --sync --quiet
eix-update
emerge -avuDN world

Wenn ich nun die binpkg-Installationen aufrufe,
brauche ich nicht mehr
emerge --sync --quiet
ausführen,
sondern kann sofort
emerge -avuDN -k world
eingeben,
dann werden die zuvor erstellten Pakete im buildpkg-System
hier angezeigt und zur Installation aufgelistet.

Der etwas längere
emerge --sync --quiet - Prozess fällt also im binpkg-System vollkommen weg,
weil alle Systeme auf ihre jeweiligen
gsy
gam
gen
Verzeichnisse zugreifen, die ja schon im buildpkg-System aktualisiert worden sind.

Diesen Vorgang habe ich heute getestet, daher dieser Bericht.

Gruß
Manfred

[ManfredB]

Heute habe ich gentoo-unstable komplett mit binpkgs installiert,
und zwar diesmal mit nouveau-Treiber anstelle von nvidia-drivers,
Grund: ich habe sys-kernel/gentoo-kernel-5.5.6 installiert, der kann nicht mit nvidia.

Die ganze Angelegenheit hat ca. 2 Stunden gedauert, dabei bin ich komplett
nach dem WIKI vorgegangen.

Und was ich hier schreibe, kommt vom plasma-Desktop, der keinerlei Schwächen zeigt,
obwohl "nur" der nouveau-Treiber vorhanden ist.

Am Ende der kompletten binpkg-Installation mache ich sicherheitshalber
noch
ermerge -avuDN world
Das war insofern gut, weil noch 59 Pakete installiert wurden.

Ich kann nur sagen, daß mich das sehr erfreut, denn es kam auf dem Weg keinerlei Fehlermeldung,
auch keine emerge @preserved-rebuild, sondern alle Pakete, die ich gruppenweise installiert habe,
konnte ich gut verfolgen.

Eine Installation auf normalem Wege kostet mich fast einen halben Tag.

Gruß
Manfred

[ManfredB]

Neuester Stand:

Nach langen Überlegungen über den Zustand auf meinen Festplatten bin ich zu einem Entschluss gelangt:

Auf SSD-I sind nun folgende Gentoo-Versionen:

Buildpkg: 3 Versionen - alle mit gentoo-kernel
Grafik-Treiber: nouveau

stable
unstable
systemd

Danach folgen die binpkg-Nutzer-Installationen:

stable
unstable
systemd

Auf SSD-II:

Buildpkg: 3 Versionen -- alle mit gentoo-sources
Grafik-Treiber: nvidia

stable
unstable
systemd

Danach folgen die binpkg-Nutzer-Installationen;

stable
unstable
systemd

So ist nun mein PC wieder mit einer guten Übersicht über die Gentoo-Installationen ausgestattet.

Allerdings bin ich nicht ausschließlich mit Gentoo beschäftigt, sondern noch mit anderen Linux-Distributionen
wie
Fedora 31
Mageia 7.1
Sabayon
ArchLinux
PCLinuxOS

Gruß
Manfred

[ManfredB]

Zu den binpkgs noch eine Anmerkung:

Auf meinem Notebook werden normalerweise alle binpkgs übernommen.

Auf meinem PC muss ich inzwischen 2 Verfahren anwenden:

1. emerge -avuDN -k world - da werden eine ganze Reihe an binpkgs installiert
2. emerge -avuDN world - da kann es passieren, daß etliche Pakete noch zusätzlich installiert werden.
Möglicherweise werden nicht alle Pakete in binpkgs verwandelt - den Grund dafür kenne ich nicht.

Aber immerhin komme ich so gut zurecht.

Gruß
Manfred

[ManfredB]

Nachtrag:

Mir sind wieder einmal Dinge aufgefallen, die mir bisher verborgen schienen.

In der /etc/portage/make.conf sind doch die Verzeichnisse eingetragen:

PORTDIR="/var/db/repos/gentoo"
DISTDIR="/var/cache/distfiles"
PKGDIR="var/cache/binpkgs"

Um den Punkt distfiles habe ich mich kaum gekümmert.

Nur dass mir heute die Idee kam:
distfiles sind ja für alle Gentoo-Versionen (stable, unstable, systemd) mehr oder weniger gleich.

Warum also sollen für jede dieser Versionen innerhalb distfiles vorliegen?

Ich habe nun eine neue Einrichtung vorgenommen:

Gehen wir einmal von der stable-Version aus:

PORTDIR="/gen/var/db/repos/gentoo"
DISTDIR="/gend/var/cache/distfiles"
PKGDIR="/gen/var/cache/binpkgs"

Wie ihr hier sehen könnt, habe ich das Verzeichnis distfiles auf eine neue Partition verlegt,
in der jeweiligen Installation liegen jetzt zwei zusätzliche Verzeichnisse:
/gen und
/gend
gend beinhaltet jetzt für alle Gentoo-Versionen:
/var/cache/distfiles

Auf diese Weise spare ich eine Menge Platz bei der Masse von distfiles,
die sich im Lauf der Zeit ansammeln.

Ich musste in allen Gentoo-Installation die make.conf ändern und natürlich die fstab,
weil das neue Verzeichnis hinzugekommen ist.

Ein etwas langer Prozess, der jetzt fertig ist.

Gruß
Manfred

[ManfredB]

Ein weiterer Punkt, der mir aufgefallen ist:

Ich trenne ja unstable und systemd, doch in den letzten Tagen wurden
kde-plasma, kde-frameworks und kde-apps aktualisiert, das war schon eine Menge
an Paketen.

Versuchsweise habe ich die unter unstable erstellten binpkgs nach systemd kopiert.
Danach ein Update unter systemd durchgeführt,
testweise
emerge -avuDN -k world

Dabei habe ich gesehen, daß die überwiegende Mehrzahl der binpkgs installiert wurden,
einige allerdings nicht, die wurden nur als Originale installiert.

Vorteil, den ich dadurch gewonnen habe:
unstable und systemd werden nun dasselbe binpkg-Pakete-Verzeichnis nutzen. Das bezieht sich aber nur
auf die 3 Gruppen: kde-frameworks kde-plasma kde-apps.

Besonders kommt mir das auf meinem Notebook zugute.

Gruß Manfred

[ManfredB]

Wieder einmal eine gute Lösung:

Auf meinem PC (mit 2 SSDs) habe ich inzwischen begonnen,
für mein Notebook gentoo-Installationen einzurichten,
die genau die gleichen Einstellungen in /etc/portage haben wie auf dem Notebook.
Ohne Desktop-Nutzung (denn Notebook: Intel und PC: NVIDIA).

Gestern abend hatte ich auf dem Notebook ein Update geplant in gentoo-siable.
gcc-9.3.0-r1 stand auf der Liste der Updates.
Gut, daß ich das dort nicht gemacht habe.
Dafür auf dem PC - wo es zwar auch lange dauert, aber die Erhitzung des Notebooks war schon etwas heftig.

Und nun kommt der Hammer: gcc-3.9.0-r1 war nun ein binpkg. Per Mini-USB-Platte habe ich das kopiert
und im Notebook ins Verzeichnis /sys-devel kopiert.

Dann emerge .-avuDN -k world - und siehe da, gcc wurde als binpkg ohne Probleme installiert.
Das hätte ich eigentlich am wenigsten vermutet, aber es hat geklappt.

Tolle Erfahrungen mache ich da.

Gruß
Manfred

[tazinblack]

sorry TL;DR

Hier mein Senf dazu:

Ich verwende da so:
Eine schnelle VM mit 32 GB RAM und 32 Cores fahre ich als "golden VM", wie ich es nenne.
Dort habe ich FEATURES="${FEATURES} buildpkg" gesetzt. Außerdem PORTDIR="/usr/portage", DISTDIR="${PORTDIR}/distfiles" und PKGDIR="${PORTDIR}/packages"

Auf dieser VM habe ich alle Pakete installiert, welche ich irgendwo verwende. Außerdem mache ich auf dieser VM die Updates.
Alle anderen VMs, welche ich verwende, bekommen von der der golden VM /usr/portage inkl. /usr/portage/packages per rsync repliziert.
Neue Maschinen sind clone von der golden VM ohne die /usr/portage/distfiles.
Dort verwende ich EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --usepkgonly".
Wenn ich dort update oder was baue, installiert er das immer aus den Binärpaketen. Nicht benötigte Pakete werden deinstalliert. Also ich benötige z.B. nicht überall einen Apache, Mariadb oder einen TFTP Server.
Wichtig ist, die Maschinen müssen immer identisch sein (USE flags, CFLAGS, etc.) wie die golden VM. Wenn ich jetzt draußen irgendwo ein noch nicht verwendetes Paket benötige, muss ich dieses erst auf der golden VM compilieren, verteilen und kann es dann draußen vom Binärpaket ausrollen.

Und das funktioniert bisher sehr gut!
_________________
Gruß / Regards
tazinblack
_______________________________________________________
what's the point in being grown up if you can't be childish sometimes

[ManfredB]

Heute wurde in unstable und systemd kde-frameworks aktualisiert.

Das mache ich immer zuerst in meinen beiden buildpkg-Installationen.

Diese binpkgs habe ich dann zu meinem Notebook übermittelt.

Doch da kam am Ende eine Fehlermeldung, rR kde-plasma/kwin.

In dem Überblick der Fehlerquelle habe ich gesehen,
daß offensichtlich meine Einstellung in der /etc/portage/make.conf
MAKEOPTS="-j4"
nicht ausreichend für kwin war. ninja als Hilfsprogramm konnte daran nichts ändern.

Da habe ich einen Versuche gestartet:
emerge --ask kde-plasma/kwin -j6

Das ist die maximale Möglichkeit auf dem Notebook.

Aber das hatte Erfolg: in wenigen Minuten war kwin reinstalliert.

Gruß
Manfred