# kein emerge mehr nach portage update

## ThuataCuSith

Moin Leute!

Ich hab da ein riesen Problen: Nachdem ich das neue Portage gezogen habe, funktioniert mein emerge nicht mehr - weder ein "world" noch ein einzelnes Paket.

Ich erhalte immer nur 

```

====================================

Error: Failed to import module 'portage_db_cdb.database'

  File "/usr/lib/portage/pym/portage.py", line 1418, in load_best_module

    mod = load_mod(best_mod)

  File "/usr/lib/portage/pym/portage.py", line 145, in load_mod

    mod = __import__(modname)

  File "/usr/lib/portage/pym/portage_db_cdb.py", line 17, in ?

    import portage_db_template

No module named portage_db_template

====================================

```

Hat einer von Euch einen Tip????

[/code]

----------

## chrib

Aus den  Release-Notes von portage-2.1:

```

* new cache framework, breaking all old cache modules.

  If you're having problems with portage_db_cdb, this is likely the cause.

```

Also schmeiss das cdb-Modul weg.

----------

## tost

Anmerkung: Portage-Versionen ab 2.1_pre6 (zur Zeit mit ~* maskiert) benötigen die cdb-Beschleunigung-Methode nicht mehr unbedingt, da das Speicherungssystem ab dort geändert wurde und von Haus aus schnell genug läuft!

Mit cdb wird das ganze aber doch noch ein bisschen schneller: http://markus-ullmann.de/gentoo/speedhack-portage-2.1

Mit portage-2.1* funktioniert das hier vorgestellte Script nicht. 

Quelle: http://de.gentoo-wiki.com/Portage_mit_cdb_beschleunigen

----------

## l3u

Dito. Einfach folgendes per Copy-&-Paste auf der Konsole ausführen, dann klappt wieder alles (als root):

```
rm /etc/portage/modules

emerge python-cdb

cd /usr/lib/portage/pym/cache

wget http://www.markus-ullmann.de/gentoo/speedhack-portage-2.1/cdb.py

mkdir -p /etc/portage

cd /etc/portage

wget http://www.markus-ullmann.de/gentoo/speedhack-portage-2.1/modules

rm -rf /var/cache/edb

emerge --metadata

```

----------

## TheSmallOne

Ich würde ja sagen das ganze ließe sich noch um einiges beschleunigen, wenn man portage gleich als richtiges Programm umsetzen würde, anstatt eine Skriptsprache zu verwenden.

Interpretersprachen sind nunmal langsammer als compiliertes.

----------

## l3u

Immer wieder die alte Diskussion ... ;-)

----------

## Yonathan

klappt super.

tolle idee  :Smile: 

----------

## l3u

@TheSmallOne: Ohne die Portage-muß-in-C-geschrieben-werden-Diskussion hier vom Zaun brechen zu wollen: imho liegt die (mangelnde?) Performance von portage nicht darin begründet, daß es in python geschrieben ist, sondern vielmehr darin, daß der portage Tree aus 100.000.000 einzelnen, kleinen Datein besteht. Eine Lösung hierzu wäre (die Devs mögen mich rügen, wenn ich Scheiß erzähle!) höchstens, von der Dateistruktur weg und hin zu einer Datenbankstruktur zu gehen. Denk ich zumindest ...

----------

## tost

@Libby

Auch diese Diskussion hatten wir bereits.

Von MySQL hin zu anderen eigens geschriebenen Datenbanksystemen

Letztendlich ist es aber nicht wirklich umsetzbar !

----------

## NightDragon

Also ich hoffe das Portage nie eine DB bekommt.

Warum? Weil der Eingriff in eine Dateistruktur weniger aufwendig ist.

Man stelle sich vor man müsste mal schnell ein ebuild ändern..

Egal. das cdb-Problem wird dir noch öfter entgegenkommen.

Ich nutze cdb schon ewig und hab das regelmäßig. - Da gabs auch mal ne Diskussion von den Entwicklern warum cdb nicht verwendet wird.

----------

## TheSmallOne

 *Libby wrote:*   

> @TheSmallOne: Ohne die Portage-muß-in-C-geschrieben-werden-Diskussion hier vom Zaun brechen zu wollen: imho liegt die (mangelnde?) Performance von portage nicht darin begründet, daß es in python geschrieben ist, sondern vielmehr darin, daß der portage Tree aus 100.000.000 einzelnen, kleinen Datein besteht. Eine Lösung hierzu wäre (die Devs mögen mich rügen, wenn ich Scheiß erzähle!) höchstens, von der Dateistruktur weg und hin zu einer Datenbankstruktur zu gehen. Denk ich zumindest ...

 

Die vielen Dateien mögen dazu beitragen, sind aber m.E. (im Vergleich zur Skriptsprache) das kleinere Übel.

Es gibt E-Mailprogramme, die auch jede einzelne Mail in einer Datei ablegen und trotzdem bei vielen Mails noch annehmbar schnell funktionieren, eben weil sie in einer Kompilationssprache geschrieben sind. Ich spreche übrigens ganz bewußt nicht von C oder C++, es gibt auch noch andere Programmierprachen (Pascal u.s.w.), aber allen gemein ist, dass sie Signifikant schneller sein dürften, als diese Skripte, die erst interpretiert werden müssen.

Optimal wäre natürlich beides (richtige Programmierprache UND Datenbank)

----------

## l3u

 *Quote:*   

> Programme [...] noch annehmbar schnell funktionieren, eben weil sie in einer Kompilationssprache geschrieben sind

 

Quod demonstrantum esset.

----------

## smg

Quod demonstrandum esset.

*scnr*

----------

## think4urs11

 *TheSmallOne wrote:*   

> Die vielen Dateien mögen dazu beitragen, sind aber m.E. (im Vergleich zur Skriptsprache) das kleinere Übel.
> 
> Es gibt E-Mailprogramme, die auch jede einzelne Mail in einer Datei ablegen und trotzdem bei vielen Mails noch annehmbar schnell funktionieren, eben weil sie in einer Kompilationssprache geschrieben sind.

 

Dir ist aber schon klar das du jetzt Äpfel mit Birnen vergleichst oder?

----------

## l3u

@smg: Schon scheiße, wenn man akademisch klugscheißen will, aber nie Latein hatte ... ;-)

----------

## tost

 *Quote:*   

> Programme [...] noch annehmbar schnell funktionieren, eben weil sie in einer Kompilationssprache geschrieben sind

 

Vielleicht auch 

quo errat demonstrator

 :Wink: 

----------

## TheSmallOne

 *Think4UrS11 wrote:*   

> Dir ist aber schon klar das du jetzt Äpfel mit Birnen vergleichst oder?

 

Wieso?

Das Argument war (frei zitiert): "Ist egal, dass es ein Skript ist, so langsam ist es nur, weil es auf so viele Dateien zugreift".

Mein Standpunkt war: "Viele Dateien machen nicht so viel aus, wie die Tatsache, dass es kein Programm (sonder Skript) ist". Und dazu habe ich angefürt, dass es Programme gibt, die mit ebensovielen Dateien arbeiten und nicht so langsam sind.

----------

## firefly

TheSmallOne: ich glaube schon das du Äpfel mit Birnen vergleichst mit deinem beispiel mit nem Mail-programm  :Smile: 

wenn du z.b. emerge -S machst dann durchsucht portage alle ebuild die sich in /usr/portage und in den möglicherweise vorhandenen Overlays und das dauert. Und da ist es egal ob portage in ner "Skript"-sprache geschreiben ist oder in einer "Komplierten" sprache.

Und ich glaube kaum das ein Mail-programm viel(signifikant) schneller ist, wenn du eine volltext-suche auf ca 23771 e-mails machst, welche im durchschnitt 42Kb groß sind.

Edit: Der vergleich hinkt etwas, da Portage die Ausgabe von den gefundenen Paketen die das suchwort enthalten etwas aufbereitet(sprich Paketname, Homepage, Desc., die eventuell installierte Version).

Das einzigste was manche kompilierte programme gegenüber manchen interpretierten programmen eventuell "besser sind", ist die geschwindigkeit beim laden des programms von der Festplatte(vorrausgesetzt die beiden programme sind vergleichbar).

----------

## l3u

imho ist außerdem auch ein in einer Scriptsprache programmiertes Programm ein Programm und nicht nur ein kompiliertes; ich würde sagen, daß alles ein Programm ist, was programmiert wurde -- und das trifft ja zumeist auch auf Scriptsprachen zu ;-)

Wie gesagt: im Fall Portage denke ich nich, daß man massive Geschwindigkeitsvorteile rausholen könnte, wenn's nicht in einer Scriptsprache geschrieben wäre, weil imo die meiste Zeit für's Zugreifen auf Dateien von der Festplatte draufgeht.

----------

