# Profile-Migration zu 17.1

## schmidicom

Heute hat mir "eselect news" ja nahe gelegt ich solle doch mal von meinem 17.0 Profil auf 17.1 migrieren. Die Sache wirkte ziemlich abenteuerlich (vor allem wegen dem Inhalt der News) aber eigentlich war es dann halb so schlimm, es mussten gerade mal drei Pakete neu gebaut und installiert werden.

sys-devel/gcc

sys-libs/glibc

sys-apps/sandbox

Wie wars bei euch? Auch so simpel oder der totale Systemcrash.

----------

## mike155

 *Quote:*   

> Wie wars bei euch? Auch so simpel oder der totale Systemcrash.

 

Danke für den Hinweis, schmidicom! Ich habe die Migration gleich mal auf einem Rechner gestartet.

Nach dem Reboot ging gar nichts mehr. Die Netzwerkkarte wurde nicht konfiguriert und auch emerge ließ sich nicht mehr starten. 

Grund waren falsche Berechtigungen von "/lib" und "/usr/lib". Mit einem

```
chmod 0755 /lib /lib64 /usr/lib /usr/lib64
```

konnte ich das jedoch beheben. Zurzeit läuft das Neucompilieren von GCC, binutils und GLIBC...

Also alles in allem: gar nicht so schlimm.

----------

## Child_of_Sun_24

Ich habe das schon vor einiger Zeit gemacht, hatte aber dank Steam mehrere 32-Bit Pakete die neu gebaut werden mussten, hatte aber keine Probleme dabei. Es klappte nach der Anleitung alles sofort.

----------

## mike155

Weiß jemand, warum man GCC, binutils und glibc nach dem Wechsel auf Profil 17.1 neu bauen soll?

In diesem Thread möchte jemand ein Binärpaket vom GCC installieren. Wenn es also Unterscheide zwischen einem GCC "vor" und "nach" dem Wechsel auf Profil 17.1 gibt: müsste es dann nicht auch unterschiedliche Binär-Pakete geben? Und müsste man das beachten, wenn man ein Binär-Paket installieren will?

----------

## schmidicom

 *mike155 wrote:*   

> Weiß jemand, warum man GCC, binutils und glibc nach dem Wechsel auf Profil 17.1 neu bauen soll?

 

Dürfte am multilib-Flag liegen das die beiden (gcc und glibc) per Default fest eingeschaltet haben.

An der Stelle habe ich mich allerdings auch erneut gewundert warum die beiden, wie alles andere, nicht auch auf das ABI_X86-Flag umgestellt wurden/werden. Natürlich hätten sie dann trotzdem neu gebaut werden müssen aber es wäre irgendwie konsequenter.

----------

## mike155

 *schmidicom wrote:*   

> Dürfte am multilib-Flag liegen das die beiden (gcc und glibc) per Default fest eingeschaltet haben. 

 

Könnte sein. Andererseits: wenn es nur das multilib-Flag ist, wären unsere Developer doch bestimmt so freundlich gewesen, der emerge-Anweisung noch eine "--newuse" Option zu spendieren???

----------

## schmidicom

 *mike155 wrote:*   

>  *schmidicom wrote:*   Dürfte am multilib-Flag liegen das die beiden (gcc und glibc) per Default fest eingeschaltet haben.  
> 
> Könnte sein. Andererseits: wenn es nur das multilib-Flag ist, wären unsere Developer doch bestimmt so freundlich gewesen, der emerge-Anweisung noch eine "--newuse" Option zu spendieren???

 

Das Flag war vorher auch aktiv, am Flag selbst hat sich also nicht geändert was emerge mit "--newuse" bemerkt hätte. Nur der Ort wo die 32bit Librarys installiert werden hat sich geändert.

Beispiel "sys-apps/sandbox":

```
...

/usr/lib32

/usr/lib32/libsandbox.so

/usr/lib64

/usr/lib64/libsandbox.so

...
```

```
...

/usr/lib

/usr/lib/libsandbox.so

/usr/lib64

/usr/lib64/libsandbox.so

...
```

----------

## mike155

 *schmidicom wrote:*   

> Nur der Ort wo die 32bit Librarys installiert werden hat sich geändert. 

 

Ah, danke! Ich kann das bei mir nicht sehen, weil ich auf allen Maschinen "no-multilib" verwende.

Aber das heißt dann, dass es bei amd64 unterschiedliche Binärpakete gibt ("vor" und "nach" der 17.1 Migration) sobald 32 Bit Libraries im Spiel sind?

----------

## Max Steel

Ich versteh nicht ganz weswegen dieser Change wirklich nötig wurde... also aus der News Meldung wurde ich nicht wirklich schlau...

----------

## schmidicom

 *mike155 wrote:*   

> Aber das heißt dann, dass es bei amd64 unterschiedliche Binärpakete gibt ("vor" und "nach" der 17.1 Migration) sobald 32 Bit Libraries im Spiel sind?

 

Ich würde da mal vorsichtig "Ja" sagen und hoffentlich prüft emerge das bei der Installation eines binary-package auch.

 *Max Steel wrote:*   

> Ich versteh nicht ganz weswegen dieser Change wirklich nötig wurde... also aus der News Meldung wurde ich nicht wirklich schlau...

 

Damit es mehr Standard konform ist, so zumindest habe ich die "eselect news" verstanden. Welcher Standard das sein soll weiß ich nicht, gemäß FSH wäre "/lib32" und "lib64" anstelle von "/lib" "/lib64" passender.

----------

## Tyrus

 *schmidicom wrote:*   

> 
> 
> Wie wars bei euch? Auch so simpel oder der totale Systemcrash.

 

*lach*

Also totaler Systemcrash würde ich nicht sagen. Aber Arbeit ist es, wobei ich das dann selber auch erheblich erweitert habe ...

Wenn man selber recht viele 32-bit Bibliotheken installiert hat (waren so >400 bei mir) dann klappt das nicht ganz so einfach wie in der News mit der Vorgehensweise. Das Kommando 

```

emerge -1v /lib32 /usr/lib32

```

läuft definitiv nicht durch. Man bekommt etliche Abbrüche die daraus resultieren das die build-Reihenfolge einfach falsch ist und man dann manuell die fehlenden Elemente selber per oneshot mergen muss. Soweit ich das sehe lässt sich das Problem auch gar nicht wirklich auflösen weil in den Abhängigkeiten Circular-Dependencies stecken und man deswegen USE-Flags abschalten muss und einige Pakete zweimal durchkompilieren muss. Ein Beispiel dazu wäre media-libs/freetype das per USE-Flag Einstellung media-libs/harfbuzz benötigt. media-libs/harfbuzz braucht aber selber media-libs/freetype. Man kann das dann auflösen mit:

```

USE="-harfbuzz" emerge --ask --verbose --oneshot media-libs/freetype

emerge --ask --verbose --oneshot media-libs/harfbuzz

emerge --ask --verbose --oneshot media-libs/freetype

```

Unabhängig von der Profil-Umstellung bei mir von 17.0 auf 17.1 war ich etwas unzufrieden mit "ABI-Mismatch"-Problemen die im Betrieb bei mir immer wieder auftauchten. Also ausgelöst vom Wechsel nach gcc:8.3.0 von gcc:7.3.0 gabs Pakete die crashten. Ein Beispiel: 

Zu media-video/mediainfo gehört /usr/bin/mediainfo-gui. Das war durch ein Update wohl schon mit dem neuen gcc gebaut worden. Im System gabs dann noch x11-libs/wxGTK (mit zwei Slots bei mir installiert: Slot 3.0-gtk3 und Slot 3.0 für gtk2). Der Stand da war noch mit  gcc:7.3.0 gebaut. Und damit crashte /usr/bin/mediainfo-gui.

Um mich langfristig von solchen Problemen die nicht immer so leicht zu erkennen sind wie bei dem Beispiel läuft bei mir jetzt einfach der komplette Neubau.

Also ich habe mich zu

```

emerge -ev @world

```

entschlossen ... *grinsschmunzel*

Das hat den Vorteil das ich grundsätzlich auch als Nebeneffekt alles nochmal durchprüfen kann (hab im Zuge der noch laufenden Aktion schon zwei Pakete gefunden die nicht mehr bauen wollen und die ich mich später dann kümmern sollte)

Mein Fazit ist das der Profilwechsel nach 17.1 nicht immer trivial ist und tendentiell, also wenn viele 32-Bit-Pakete vorhanden sind, manuelle Arbeiten erfordert und man das ganze mit ausreichend Zeit machen sollte ..,

Ansonsten klappt aber alles gut hier ...  :Wink: 

----------

## Kuhrscher

Bei mir ist das auf dem Server und dem Desktop ohne Probleme heute durchgelaufen.

----------

## mike155

Manche Probleme zeigen sich wohl erst später: https://forums.gentoo.org/viewtopic-t-1097704.html. Ich vermute, dass in den nächsten Tagen noch weitere Problemchen auftauchen werden.

----------

## Tyrus

Die X11-Biblios sind in der Build-Reihenfolge leider falsch (also bei  'emerge -1v /lib32 /usr/lib32 ') und das geht recht tief rein. Es werden keine Abhängigkeiten der Pakete untereinander beachtet. Ich musste da auch etliches per oneshot und nach Fehleranalyse mergen. Es geht aber ansich trotzdem soweit man selber in der Lage ist die Konfigurierungsphase der Pakete zu verstehen. Ist halt dann nur Arbeit ... Deswegen meinte ich ja das man für den Profilwechsel Zeit einplanen sollte wenn man wirklich eine grössere Zahl 32-Bit Bibliotheken im System hat.

----------

## franzf

Danke für die Infos. Gut dass ich noch gewartet habe. Hatte mal wine und acroread installiert und immer noch die 32bit-Einträge in package.use stehen.

Baue gerade 98 Pakete neu, die mir beim Profil-upgrade sicher Probleme bereitet hätten...

----------

## ManfredB

Ich will eine Neu-Installation machen,

doch das funktioniert mit dem neuen Profil 17.1 bei mir nicht,

sobald ich eines der Programme neu programmieren will, kommt immer wieder die Meldung

```

 ERROR: app-portage/unsymlink-lib-13::gentoo failed (setup phase):

 *   ERROR: 17.1 migration has not been performed!!

```

Dabei gehe ich genau nach den dort beschriebenen Schritten vor.

Oder ist das bei einer Neuinstallation nicht möglich?

Ich habe Profil 34 gewählt: plasma

Seltsam finde ich das.

Verstehe ich das richtig, daß es nur geht, wenn man von einer vorhandenen Installation umwechselt auf das neue Profil?

Dann ist also der Weg über eine Neuinstallation nicht möglich.

Gruß

Manfred

----------

## Tyrus

app-portage/unsymlink-lib ist für den Profilwechsel von 17.0 nach 17.1. Wenn du schon auf 17.1 stehst ist es sinnlos.

Profile 17.1 braucht keine symbolischen Links mehr (also kein /lib32 und kein /usr/lib32). Damit ist app-portage/unsymlink-lib sinnlos, weil es diese jetzt veralterte Systemarchitektur umstellt. Profil 17.1 hat ja den neuen Aufbau.

Wenn du dein System neu aufsetzt (also weil du Neuinstallation schreibst) und gleich das Profil 17.1 auswählst musst du da nichts machen.

Solltest du dein System umstellen wollen von Profil 17.0 nach 17.1 dann musst du erst für die ersten Schritte noch auf Profil 17.0 bleiben und erst wie in der news beschrieben das Profil im Verlauf wechseln.

----------

## ManfredB

Aber als ich mit der Neuinstallation umgegangen bin,

habe ich nach der Anleitung das Profil ausgewählt und dann

ein grundsätzliches Update durchführen wollen,

und genau das hat nicht geklappt, weil 17.1 offensichtlich nicht performed ist - oder wie das heisst.

Jetzt versuche ich es mal bei einer schon bestehenden Installation.

Gruß

Manfred

----------

## ManfredB

So, nun habe ich meine bestehende gentoo-stable-Installation auf Profil 34 (plasma) umgestellt.

Es hat alles geklappt.

Gruß

Manfred

----------

## ManfredB

Heute will ich es mit einer Neuinstallation testen,

allerdings anders, als ich es gestern hier berichtet habe,

Die Basis-Installation mache ich wie gewöhnt mit  Profile 17.0.

Sobald das System selbst bootfähig ist, beginne ich mit den Schritten der Umstellung.

Dann erst werde ich mir das Weitere installieren, was ich sonst auch nutze:

zuerst kde-plasma/plasma-meta

Danach installiere ich von KDE nur das, was ich wirklich brauche,

vor allem ohne qtwebengine.

Bin gespannt, was dabei herauskommt.

Gruß

Manfred

----------

## ManfredB

Die Basis-Installation ist komplett fertig,

nach Reboot habe ich die Umstellung komplett durchgeführt.

Und nun läuft gerade in einem längeren Prozess

kde-plasma/plasma-meta.

Fazit: es gelingt, wenn man das erste Update in der chroot-Umgebung durchgeführt hat.

Ohne dieses Update hatte es in meinem ersten Versuch nicht geklappt, was mir nun

komplett einleuchtet.

Gruß

Manfred

----------

## schmidicom

Um mal wieder zum eigentlichen Thema zurück zu kommen (Hilfe sucht/findet man in einem anderem Bereich des Forum, Danke.).

Bei mir hat sich seit der Umstellung nur ein Package etwas merkwürdig verhalten, nämlich "kde-apps/ktp-call-ui". Dessen build-script konnte die Library "libfarstream-0.2.so.5" nicht mehr finden weil es diese stur in "/usr/lib/" suchte anstelle von "/usr/lib64" (kleine Info am Rand: "net-libs/farstream" hat diese Lib auch schon vor der Umstellung in "/usr/lib64" installiert, am Standort der Lib hat sich also nichts geändert). Noch seltsamer war das sich dieser Fehler nur durch ein "emerge --oneshot $(qlist -IC telepathy)" beheben lies, danach suchte das build-script von "kde-apps/ktp-call-ui" dann plötzlich am richtigen Ort nach der Lib.  :Shocked: 

Bin mal gespannt was mit der Zeit eventuell noch so zum Vorschein kommt.  :Wink: 

EDIT: Abgrund gefunden!

Ich glaube ich weiß jetzt wo das hergekommen ist. Die Datei "/usr/lib64/cmake/TelepathyQt5Farstream/TelepathyQt5FarstreamConfig.cmake" enthält harte Pfadangaben und vielleicht stolpert das cmake bei "kde-apps/ktp-call-ui" genau darüber wenn diese noch auf das alte Verzeichnis zeigen. Um das zu beweisen habe ich nach weiteren Packages gesucht und bin fündig geworden.

"/usr/lib64/cmake/LibIcal/LibIcalTargets.cmake" von "dev-libs/libical":

```
/usr/lib64/cmake/LibIcal/LibIcalTargets.cmake:  INTERFACE_LINK_LIBRARIES "ical;/usr/lib/libdb.so"
```

```
/usr/lib64/cmake/LibIcal/LibIcalTargets.cmake:  INTERFACE_LINK_LIBRARIES "ical;/usr/lib64/libdb.so"
```

Gefunden habe ich diese cmake-Datei mit dem folgenden Befehl:

```
egrep -ri "lib/" /usr/lib64/cmake/
```

Bevor ich hier aber einen unnötigen Bugreport lostrete wäre es schön wenn jemand mit etwas mehr Ahnung das reproduzieren könnte.

----------

## nisto

Hallo.

Mein Umstellung hat gut funktioniert. Allerdings konnte ich nach dem reboot zum neuen Profile keine WLAN Verbindung aufbauen, der wpa_supplicant brachte Fehlermeldungen. Es stellte sich heraus, dass der wpa_supplicant schon lief. Nachdem ich diesen beendet hatte konnte ich mich wieder normal verbinden. Mir ist noch aufgefallen, dass die Schnittstellen schon hochgefahren waren, was ich vorher  nicht eingestellt habe.

Meine Frage ist. Ist das im Profile standardmäßig verankert und wie kann ich das wieder abstellen?

Viele Grüße,

Nico

----------

## firefly

 *schmidicom wrote:*   

> 
> 
> "/usr/lib64/cmake/LibIcal/LibIcalTargets.cmake" von "dev-libs/libical":
> 
> ```
> ...

 

Ich vermute diese Files werden von den entsprechenden Pakten beim bauen erstellt. Daher sollte es wohl reichen die entsprechenden Pakte neu zu bauen.

Was wohl bei dir auch funktioniert hat mit libical.

----------

## schmidicom

 *firefly wrote:*   

> Ich vermute diese Files werden von den entsprechenden Pakten beim bauen erstellt.

 Davon gehe ich auch aus.

 *firefly wrote:*   

> Daher sollte es wohl reichen die entsprechenden Pakte neu zu bauen. Was wohl bei dir auch funktioniert hat mit libical.

 Ein rebuild korrigiert zwar den Inhalt solcher Dateien aber gefährlich ist das trotzdem. Denn solche Dateien werden zum Beispiel von einem revdep-rebuild ja nicht erkannt und doch können sie den build-Prozess anderer Packages blockieren ohne im build.log dieser Packages erwähnt zu werden.

@nisto

Mir wäre nicht aufgefallen das beim Wechsel von 17.0 zu 17.1 irgendetwas an der Startkonfiguration (welche Dienste/Treiber wann und unter welchen Bedingungen gestartet/geladen werden) verändert würde.

----------

## nisto

 *schmidicom wrote:*   

> 
> 
> @nisto
> 
> Mir wäre nicht aufgefallen das beim Wechsel von 17.0 zu 17.1 irgendetwas an der Startkonfiguration (welche Dienste/Treiber wann und unter welchen Bedingungen gestartet/geladen werden) verändert würde.

 

Ich konnte bei meiner kurzen Suche im Netz auch nichts finden. Es trat aber just das 1.Mal nach dem Profilwechsel auf, vielleicht auch Zufall. Am Wochenende will ich mich noch mal ein bisschen im System umsehen.

----------

## tazinblack

 *schmidicom wrote:*   

> Heute hat mir "eselect news" ja nahe gelegt ich solle doch mal von meinem 17.0 Profil auf 17.1 migrieren. Die Sache wirkte ziemlich abenteuerlich (vor allem wegen dem Inhalt der News) aber eigentlich war es dann halb so schlimm, es mussten gerade mal drei Pakete neu gebaut und installiert werden.
> 
> sys-devel/gcc
> 
> sys-libs/glibc
> ...

 

Ich habs noch nicht angefangen. Was für ein Profil hast Du denn verwendet / verwendest Du denn genau?

Mir stellt sich die Frage, wie lange das 17.0 Profil noch vorhanden sein wird.

----------

## schmidicom

 *tazinblack wrote:*   

> Was für ein Profil hast Du denn verwendet / verwendest Du denn genau?

 

Bei meinem PC und Laptop ging die Reise von "default/linux/amd64/17.0/desktop/plasma/systemd" zu "default/linux/amd64/17.1/desktop/plasma/systemd".

 *tazinblack wrote:*   

> Mir stellt sich die Frage, wie lange das 17.0 Profil noch vorhanden sein wird.

 

Keine Ahnung aber jetzt wo 17.1 als stable angesehen wird dürfte es wohl nicht mehr lange dauern bis 17.0 als obsolete markiert und dann irgendwann ganz raus fliegt.

Ich selbst müsste noch einen letzten Server umstellen aber das werde ich bei diesem erst machen wenn der Moment günstig ist, wenn also bei einem eventuellen Ausfall nicht all zu viele betroffen sind. Hoffentlich bleibt bis dahin das Profil noch am leben.

----------

## ManfredB

Ich bin gerade dabei, einen neuen Versuch zu starten:

Installation sofort mit Profil 17.1 - wie gehe ich vor.

Ich habe in einer chroot-Umgebung erst einmal

app-portage/unsymlink-lib installiert,

dann habe ich eins nach dem anderen durchgeführt:

unsymlink-lib --analyze

unsymlink-lib --migrate

unsymlink-lib --finish

Danach eselect profile list,

eselect profile set 23

plasma

emerge --ask --verbose --update --deep --newuse @world

Und nun werden 263 Pakete aktualisiert - ohne Fehler bisher.

Fazit: es geht auch erheblich schneller so.

Ob es am Ende noch irgendein Problem gibt, teile ich mit, wenn dieses Update fertig ist.

Gruß

Manfred

Fazit: das Basis-System ist direkt mit Profil 17.1 erfolgreich installiert worden.

----------

## mike155

 *Quote:*   

> dürfte es wohl nicht mehr lange dauern bis 17.0 als obsolete markiert und dann irgendwann ganz raus fliegt.

 

Ich habe die Umstellung recht genau mitverfolgt. Bei mir lief alles relativ problemlos - aber in den englischsprachigen Foren gab es viele Support-Anfragen. Teilweise hatten 20-30% der Anfragen damit zu tun. Mittlerweile ist der Anteil der Support-Anfragen wieder etwas geringer geworden. Aber dafür sehe ich viele Anfragen (zu anderen Themen), bei denen aus 'emerge --info' hervorgeht, dass die User noch Profil 17.0 verwenden - und gar nicht planen, auf 17.1 zu wechseln.

Ein größerer Teil der Gentoo User hat also wohl noch gar nicht auf Profil 17.1 umgestellt. Vermutlich werden diese User auch erst denn wechseln, wenn sie müssen. Falls also Profil 17.0 in naher Zukunft entfernt werden sollte, wird es noch mal einen ganzen Schwung verzweifelte User geben.

----------

## Max Steel

Okay, also ich bin jetzt auch dabei auf einem Arbeits-PC...

Soweit so smooth. beim rebuild der Programme in /usr/lib32 (und co) brechen mir die ganzen libX* Libs mit Fehler während dem Configure ab. ein Blick in die Fehlermeldung und die Buildorder scheint etwas zutage zu befördern:

```
checking for nl_langinfo... yes

checking for X11... no

configure: error: Package requirements (xproto >= 7.0.17 xextproto xtrans xcb >= 1.11.1 kbproto inputproto) were not met:

No package 'xcb' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you

installed software in a non-standard prefix.

Alternatively, you may set the environment variables X11_CFLAGS

and X11_LIBS to avoid the need to call pkg-config.

See the pkg-config man page for more details.

```

In der Buildorder ist libxcb vorhanden. aber erst später:

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

Calculating dependencies... done!

[ebuild   R    ] sys-libs/gpm-1.20.7-r2::gentoo  USE="(-selinux) -static-libs" ABI_X86="32 (64) (-x32)" 0 KiB

[ebuild   R    ] dev-db/sqlite-3.28.0:3::gentoo  USE="icu readline secure-delete -debug -doc -static-libs -tcl -test -tools" ABI_X86="32 (64) (-x32)" 0 KiB

[ebuild   R    ] x11-libs/libxcb-1.13.1:0/1.12::gentoo  USE="xkb -doc (-selinux) -static-libs -test" ABI_X86="32 (64) (-x32)" 0 KiB

[ebuild   R    ]  x11-base/xcb-proto-1.13::gentoo  ABI_X86="32 (64) (-x32)" PYTHON_TARGETS="python2_7 python3_6 -python3_5 -python3_7" 0 KiB

```

Warum er die lib nicht findet, obwohl diese ja offiziell vorhanden sein müsste und nur rebuilded wird, erschließt sich mir nicht ganz.

/usr/lib/libX11-xcb.so

Aber egal, ich hab den mit --keep-going gestartet, also erstmal abwarten, wenn alles gut geht muss ich den rebuild einfach nur nochmal durchführen.

Keine Ahnung.

Edith sagt:

Das selbe passiert beim Paket dev-libs/glib wegen libmount (aus dem Paket sys-apps/util-linux)

Edith die 2.:

für glib hat sich das bewahrheitet.

Okay. also wird der Rest auch durchreiten.

Edith die letzte:

Wie gesagt, ein zweiter Run von emerge -1v --deep /lib32 /usr/lib32 /usr/lib/llvm/*/lib32 lief jetzt problemlos durch. Er hat z.G. auch beim zweiten mal nur die Ebuilds mit Fehlern gezogen.

Auf jedenfall war das seltsam.

----------

## ChrisJumper

Auf zwei Systemen hatte ich bisher keine Probleme. Zuerst immer aktuallisiert und dann wie in den News vorgegangen.

Aber jetzt....:

```
# unsymlink-lib --analyze

/usr/lib needs to be a symlink to lib64!
```

```
 /usr # ls -lah lib

lrwxrwxrwx 1 root root 7 11. Jul 03:14 lib -> ./lib64
```

Übersehe ich etwas? Aktuell verwende ich das Profil 17.0.

Edit: Solved.

```
 # cd /usr

# rm lib && ln -s lib64 lib
```

Dann geht's. Es hatte sich wohl nur an dem relativen Angabe verschluckt. Ich musste lediglich zwei drei alte Pakete noch entfernen wie: x11-apps/mkfontdir, oder x11-libs/libXp.

Aber das wurde dann gemeldet mit dem Hinweis das es im aktuellen Tree ein solches Paket nicht mehr gibt und das System diese Abhängigkeit deswegen nicht mehr neu bauen kann.

Tipp: an alle die es noch vor sich haben:

- Zuvor schauen das emerge -u @world durch gelaufen ist. Wie in der Anleitung der News von Profil 17.0 auf 17.1 zu wechseln ist dann relativ unkompliziert.

Wenn man es noch nicht gemacht hat, also ein sehr altes System auf den neuen Stand hebt, vielleicht auch noch pearl und python zuvor aktualisieren. Wenn man es verwendet auch die qt Pakete.

Läuft dann emerge -u @world durch und findet auch keine weiteren Aktualisierungen sieht es schon sehr gut aus.

Tipp 2:

Wenn man sich sicher ist das man bestimmte Compilervarianten nicht in mehreren Slots benötigt sollte man die vorher entfernen.

Beispielsweise unnötige Slots bei

sys-devel/gcc

sys-devel/llvm

dev-lang/rust

Wobei bei Rust halt kein Slot da ist, aber eine Updatemöglichkeit. Ich freue mich auf schwächeren Systemen über rust-bin. :)

----------

## ManfredB

Heute habe ich eine Neuinstallation begonnen

und dabei habe ich festgestellt,

daß im Basis-Verzeichnis keine /lib32 und /usr/lib32 mehr vorkommen,

außerdem ist bei der Auswahl des Profils bereits 17.1. voreingestellt,

was man dann noch auswählen kann im selben Profil, zB plasma - wie bei mir - oder

was sonst ausgewählt wird.

Damit ist der ganze Prozess des Ummodelns überflüssig geworden.

Gruß

Manfred

P.S. Das geht nur mit einer Neuinstallation.

Bestehende Installationen mit älteren Profilen müssen den Umwandlungsprozess dennoch durchführen.Last edited by ManfredB on Thu Jul 18, 2019 6:13 am; edited 1 time in total

----------

## ChrisJumper

 *ManfredB wrote:*   

> 
> 
> Damit ist der ganze Prozess des Ummodelns überflüssig geworden.
> 
> 

 

Hi ManfredB,

aber so muss man dann ja die Daten trotzdem migrieren oder das Backup nutzen. Ich vermute auch das man halt mehr Compilieren muss. Aber generell ist es vorteilhaft mal alles zu entfernen was man nicht braucht... als auch ein Backup zu haben, für den Fall das ein Krypto-Trojaner zuschlägt.

Ich fand den Wechsel aber bisher gar nicht so schwierig... muss jetzt nur noch die Server migrieren.

Gruß

Chris

----------

## ManfredB

Und nun kommt der Hammer:

/usr/portage gibt es nicht mehr.

Unter /var/cache findet man nun 2 Verzeichnisse,

/distfiles

/binpkg

Das zweite ist neu.

Die /usr/portage-Verzeichnisse liegen unter /var/db/repos/gentoo

Ein deutlicher Umbau des Systems - wie ich finde, aber kein Problem.

Gruß

Manfred

----------

## ManfredB

Ich habe in den letzten Tagen 2 Neuinstallationen durchgeführt.

Eine gentoo-stable und eine gentoo (ACCEPT_KEYWORDS="~amd64")

Ich muss sagen, daß - nach der Einführung von Profil 17.1 - jetzt wieder alles

so einfach ist wie bisher.

Nur die Sache mit /usr/portage (die bei emerge-webrsync als fehlend gekennzeichnet wurde)

hat sich doch aus /usr nach /var verlagert, dort allerdings jetzt mit dem neuen Verzeichnis

/var/db/repos/gentoo.

Bisher habe ich für das Verzeichnis /usr eine 20Gb-Partition zur Verfügung gestellt (33%),

für /var nur 10G (11 %).

Die /root-Partition (10 GB) wird nur mit 36% belastet, das heisst, ich könnte die auch kleiner anlegen.

Aber da ich genügend Platz zur Verfügung habe, spielt das bei mir keine so große Rolle.

Bei der amd64-Installation ist etwas merkwürdiges passiert.

Ein Paket konnte nicht installiert werden, da liefen irrsinnig viele Seiten von Infos über den Bildschirm,

nichts davon konnte ich lesen, weil das Tempo geradezu rasend war.

In der build.log habe ich nichts gefunden, was diesen Fehler verursacht hat.

Da bin ich in mein Verzeichnis, wo ich die buildpkgs speichere, gegangen und habe nach diesem Programm geschaut.

Ich habe es gefunden, auch dieselbe Version, habe statt

emerge --ask sys-~/~

einfach 

emerge --ask -k sys-~/~

eingegeben, und was ich kaum glauben konnte,

das Paket wurde anstandslos installiert.

Damit war das Problem auf sehr einfache Weise behoben und ich konnte die restlichen Pakete

auch noch installieren.

Leider weiß ich den Namen des Pakets nicht mehr.

Fazit für mich:

Es macht auf der Basis von Profil 17.1 genauso viel Spaß wie zuvor.

Das wünsche ich allen Gentoo-Freunden, die sich an eine Neuinstallation heranmachen.

Gruß

Manfred

P.S. nun wollte ich die systemd-Variante auch ausprobieren, doch die ist noch nicht so weit.

----------

## ManfredB

Fazit:

1. Bei einer Umstellung eines bestehenden Systems auf Profil 17.1 bleibt /usr/portage.

2. Bei einer Neuinstallation von gentoo ändert sich das in /var/db/repos/gentoo

Gruß

Manfred

----------

