# esearch-0.8 preview: eupdatedb endlich wieder schnell?

## haceye

Hi,

Ich hab mich grad mal hingesetzt und den Indexing-Prozess von eupdatedb komplett umgeschrieben. Einige von euch wissen ja vielleicht, dass in der letzten Zeit eupdatedb immer langsamer wurde.

Das neue eupdatedb arbeitet mit den Daten aus /var/cache/edb/dep, und benutzt auch portage nicht mehr, um herauszufinden, welches die "available", und welches die "installed" Version ist, sondern macht dies selbst.

Dadurch läuft bei mir eupdatedb jetzt wieder viel schneller.

```

shark (~/python/esearch/esearch-0.8) $ ./eupdatedb.py

 * Searching all ebuilds

 * indexing: 0 ebuilds to go

 * esearch-index generated in 1 minute(s) and 18 second(s)

 * indexed 8226 ebuilds

 * size of esearch-index: 1327 kB

```

Ich hab auch noch ein neues Feature eingebaut, dass das indexing der "Size of downloaded files" ausschaltet, da das die meiste Zeit verbraucht, und da ich da eigentlich sowieso nie draufschaue.

```

shark (~/python/esearch/esearch-0.8) $ ./eupdatedb.py --nofilesize

 * Searching all ebuilds

 * indexing: 0 ebuilds to go

 * esearch-index generated in 10 second(s)

 * indexed 8226 ebuilds

 * size of esearch-index: 1275 kB

```

Es wäre schön, wenn ein paar von euch das neue esearch mal testen könnten. Ihr müsstet dazu das ebuild von esearch-0.7 in euer Portage Overlay kopieren (/usr/local/portage/app-portage/esearch), dann ebuild digest esearch-0.8.ebuild, und schließlich emerge esearch.

Das ist aber noch nicht die fertige 0.8er Version!

David

----------

## zielscheibe

Wie soll ich denn, von der 0.7 Version zum 0.8er ebuild kommen, ohne einen Downloadlink  :Question: 

----------

## haceye

Du müsstest eigentlich das esearch-0.7.ebuild unter /usr/portage/app-portage/esearch/ haben.

----------

## _hephaistos_

hi david!

cooles script - wollt ich schon länger mal sagen! thx dafür!

habs 2x laufen lassen:

```

root@localhost:~> eupdatedb --nofilesize

 * Searching all ebuilds

 * indexing: 0 ebuilds to go

 * esearch-index generated in 21 second(s)

 * indexed 8299 ebuilds

 * size of esearch-index: 1288 kB

root@localhost:~> eupdatedb --nofilesize

 * Searching all ebuilds

 * indexing: 0 ebuilds to go

 * esearch-index generated in 9 second(s)

 * indexed 8299 ebuilds

 * size of esearch-index: 1288 kB

```

wenn du noch mehr infos brauchst - sags ruhig  :Smile: 

ciao

----------

## psyqil

 :Shocked:  Rock'n Roll!  :Cool:  Das flitzt ja wieder! Super, dankeschön!  :Very Happy: 

```
cerebella ~ # esync --nofilesize 

 * Error: option --nofilesize not recognized (see --help for all options)
```

Kann man da noch was dran machen?

----------

## zielscheibe

Hab ich ja auch.  :Smile: 

Einmal nach deiner Anleitung "esearch-0.7.ebuild" in das neue Overlay kopiert. Aber wie soll "ebuild esearch-0.8.ebuild digest" funktionieren, wenn ein solches Ebuild nicht vorhanden ist?

```

zielscheibe esearch # vdir

insgesamt 8

-rw-r--r--  1 root root    1055  5. Jan 16:09 esearch-0.7.ebuild

drwxr-xr-x  2 root root      88  5. Jan 16:40 files

-rw-rw-r--  1 root portage  126  5. Jan 16:42 Manifest

zielscheibe esearch # pwd

/usr/local/portage/app-portage/esearch

zielscheibe esearch # ebuild digest esearch-0.8.ebuild

!!! Name error in : missing a version or name part.

!!! Error: PF is null ''; exiting.

zielscheibe esearch #

```

/edit

Holla, da stand ich ganz arg auf dem Schlauch.   :Embarassed: 

Des 0.7er ebuilld mußte nat. als 0.8er ins Overlay kopiert werden.   :Embarassed: 

Heftiges Speedup (vorher ~13 Minuten)!  :Razz: 

```

eupdatedb 

 * Searching all ebuilds

 * indexing: 0 ebuilds to go   

 * esearch-index generated in 17 second(s)

 * indexed 8649 ebuilds

 * size of esearch-index: 1381 kB

zielscheibe esearch # 

```

Last edited by zielscheibe on Wed Jan 05, 2005 3:59 pm; edited 1 time in total

----------

## _hephaistos_

schau!

ich hoff ich vertipp mich nicht!

```

cp /usr/portage/app-portage/esearch/esearch-0.7.ebuild /usr/local/portage/app-portage/esearch/esearch-0.8.ebuild

cd /usr/local/portage/app-portage/esearch/

ebuild esearch-0.8.ebuild digest

wenn der download net geht, händisch runterladen:

http://david-peter.de/downloads/

emerge esearch -pv -> sollte 0.8 ausgeben!

```

mit anderen worten: 0.7 in 0.8 umbennen und ins overlay damit!

hth,

ciao

----------

## haceye

Du musst das esearch-0.7.ebuild in den Overlay-Ordner kopieren, und gleichzeitig umbenennen in esearch-0.8.ebuild  :Wink: 

```

cp /usr/portage/app-portage/esearch-0.7.ebuild /usr/local/portage/app-portage/esearch-0.8.ebuild

cd /usr/local/portage/app-portage/

ebuild esearch-0.8.ebuild digest

emerge esearch

```

ciao,

David

----------

## _hephaistos_

he haceye,

hast auch den pfad falsch  :Smile: 

 app-portage/ESEARCH/ebuild 

dh: category/package/ebuild...

hth,

ciao

----------

## haceye

 *hephaistos6 wrote:*   

> he haceye,
> 
> hast auch den pfad falsch 
> 
>  app-portage/ESEARCH/ebuild 
> ...

 

Ähm ja, sorry  :Wink: 

Aber du hasts ja eh scho geschrieben, wie's geht

----------

## rukka

Auch von mir ein dickes dankeschön haceye  :Wink: 

Bisher läuft die Preview der 0.8 Version ohne Probleme und selbst auf meinem betagten C-Athlon bekomme ich diese Resultate:

```
~ # eupdatedb 

 * Searching all ebuilds

 * indexing: 0 ebuilds to go   

 * esearch-index generated in 12 second(s)

 * indexed 6168 ebuilds

 * size of esearch-index: 1002 kB

~ #
```

Da kann man sich doch nicht beschweren, oder?  :Very Happy: 

Ciao, rukka

----------

## haceye

 *psyqil wrote:*   

> 
> 
> ```
> cerebella ~ # esync --nofilesize 
> 
> ...

 

Klar, das kommt bestimmt noch.

----------

## Der P@te

Es rockt  :Smile:  Danke  :Very Happy: 

----------

## reyneke

 *eupdatedb wrote:*   

> 
> 
>  * Searching all ebuilds
> 
>  * indexing: 0 ebuilds to go   
> ...

 

 *eupdatedb --nofilesize wrote:*   

> 
> 
> * Searching all ebuilds
> 
>  * indexing: 0 ebuilds to go   
> ...

 

 :Sad:  leider bei mir keine so drastische Leistungssteigerung, aber dennoch respektabel. Früher brauchte das deutlich über 10 min. 

Abgesehen davon ein ganz dickes Dankeschön für das Skript. Ich käme schlecht ohne aus.

Gruß,

reyneke.

----------

## psyqil

Nach esync:

```
 * Searching for changes

[MN] sys-kernel/mips-sources (2.6.10):  GPL-2

[ N] media-sound/mpg123 (0.59s-r9):  as-is

[ N] sci-mathematics/pari (2.1.5-r3):  GPL-2

[MN] media-sound/potamus (20040414):  GPL-2

[ U] net-dialup/ppp (2.4.2-r10):  BSD GPL-2

[MN] media-gfx/quickplot (0.8.5):  GPL-2
```

mit esearch -c das gleiche... da stand doch früher was anderes als die Lizenz, oder?  :Razz: 

----------

## haceye

 *psyqil wrote:*   

> ...mit esearch -c das gleiche... da stand doch früher was anderes als die Lizenz, oder? 

 

Oh, esync ist noch gar nicht geupdated, danke für den Hinweis.

Interessant wäre, ob die Versions-Informationen überall noch richtig sind, das is eigentlich das heikle Thema.

David

----------

## Anarcho

Das Problem mit der Anzeige bei esync ist mir auch gerade aufgefallen, da ich das vom Crondeamon machen lasse und mir das ergebnis zugemailt wird.

Schön fände ich es wenn die Ausgabe bei esync nach kategorie sortiert wäre. Wäre das möglich, vielleicht per parameter?

----------

## piquadrat

Vorher:

 * esearch-index generated in 26 minute(s) and 54 second(s)

(Disclaimer: ich habe relativ viele Einträge in /etc/portage/package.*, aber alle korrekt formatiert)

Nachher:

 * esearch-index generated in 1 minute(s) and 29 second(s)

DAAAAANKEEE! 

/me ist happy

----------

## Lenz

```
sulfur /home/lenz # eupdatedb

 * Searching all ebuilds

 * indexing: 0 ebuilds to go

 * esearch-index generated in 6 second(s)

 * indexed 546 ebuilds

 * size of esearch-index: 92 kB

```

Wieso idiziert der bei mir nur 546 ebuilds? Das müssten doch viel mehr sein, oder?

----------

## psyqil

Hatte ich gestern auch, aber nur einmal, danach ging's wieder... Ich dachte, es hätte mit meinen vorherigen "Wartungsarbeiten" zu tun gehabt...

----------

## icefox13

Schön! Nur noch zwei Minuten statt.. mindestens fünfmal so viel  :Wink: 

Jetzt kann ich das Teil endlich wieder in einen daily cronjob packen  :Smile: 

----------

## Lenz

```
sulfur /home/lenz # eupdatedb

 * Searching all ebuilds

 * indexing: 0 ebuilds to go

 * esearch-index generated in 58 second(s)

 * indexed 8337 ebuilds

 * size of esearch-index: 1347 kB

```

Komisch, seit dem letzten --sync geht's bei mir auch wieder. Naja mich freut's. Klappt super & schnell!  :Smile: 

----------

## haceye

 *Lenz wrote:*   

> 
> 
> ```
> sulfur /home/lenz # eupdatedb
> 
> ...

 

Naja, das is natürlich blöd. Das basiert jetzt auf den Cache-Daten in /var/cache/edb/dep. Ich hab leider keine Ahnung, wann die aktuell sind, und wann nicht.

Muss ich noch rausfinden bis zur 0.8-final

David

----------

## platinumviper

 *haceye wrote:*   

> Interessant wäre, ob die Versions-Informationen überall noch richtig sind, das is eigentlich das heikle Thema.

 

Ich hab mich mal mit ein paar alten Freunden (cp, vim, sort, cut, mgdiff) zusammengesetzt und die ersten fünf Felder der alten und neuen /var/cache/edb/esearchdb.py betrachtet. Die Felder pkgname, pkg und vinstalled sind immer identisch, die Felder masked und vavail unterscheiden sich jedesmal, wenn ein Paket in /etc/portage/package.* (de)maskiert wurde. Z.B.:

```
mars ~ # esearch bug-buddy

[ Results for search key : bug-buddy ]

[ Applications found : 1 ]

*  gnome-extra/bug-buddy

      Latest version available: 2.6.1

      Latest version installed: 2.8.0

      Size of downloaded files: 838 kB

      Homepage:    http://www.gnome.org/

      Description: Bug Report helper for Gnome

      License:     GPL-2

mars ~ # etcat -v !$

etcat -v bug-buddy

[ Results for search key           : bug-buddy ]

[ Candidate applications found : 5 ]

 Only printing found installed programs.

*  gnome-extra/bug-buddy :

        [M  ] 2.0.8 (1)

        [   ] 2.4.2 (2)

        [   ] 2.6.0 (2)

        [   ] 2.6.1 (2)

        [  I] 2.8.0 (2)

mars ~ # grep !$ /etc/portage/package.keywords

grep bug-buddy /etc/portage/package.keywords

gnome-extra/bug-buddy   ~amd64

mars ~ #

```

Und dann hab ich noch den seltenen Fall gefunden, in dem ein Paket installiert, in dieser Version aber nicht mehr im Portage-Tree vorhanden ist:

```
mars ~ # esearch blender

[ Results for search key : blender ]

[ Applications found : 1 ]

*  media-gfx/blender [ Masked ]

      Latest version available: 2.36-r1

      Latest version installed: [ Not Installed ]

      Size of downloaded files: 6,750 kB

      Homepage:    http://www.blender.org/

      Description: 3D Creation/Animation/Publishing System

      License:     || (GPL-2 BL)

mars ~ # emerge -pvu blender

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

Calculating dependencies

!!! All ebuilds that could satisfy "blender" have been masked.

!!! One of the following masked packages is required to complete your request:

- media-gfx/blender-2.35 (masked by: package.mask, ~amd64 keyword)

# <lu_zero@gentoo.org> (02 Dec 2004)

# Masking since this version is broken

- media-gfx/blender-2.34-r1 (masked by: ~amd64 keyword)

- media-gfx/blender-2.36 (masked by: ~amd64 keyword)

- media-gfx/blender-2.36-r1 (masked by: missing keyword)

- media-gfx/blender-2.34 (masked by: ~amd64 keyword)

For more information, see MASKED PACKAGES section in the emerge man page or

section 2.2 "Software Availability" in the Gentoo Handbook.

mars ~ # emerge -pC blender

>>> These are the packages that I would unmerge:

 media-gfx/blender

    selected: 2.32

   protected: none

     omitted: none

>>> 'Selected' packages are slated for removal.

>>> 'Protected' and 'omitted' packages will not be removed.

mars ~ # grep blender /etc/portage/package.*

/etc/portage/package.keywords:=media-gfx/blender-2.32   ~amd64

```

Tja, ich hätte meine package.keywords wohl besser pflegen sollen  :Embarassed:  , ich lass das mal so, dann hilft es wenigstens bei der Fehlersuche.

Vielen Dank für dieses kaum wegzudenkende Paket  :Very Happy: 

platinumviper

----------

## haceye

 *platinumviper wrote:*   

> Ich hab mich mal mit ein paar alten Freunden (cp, vim, sort, cut, mgdiff) zusammengesetzt und die ersten fünf Felder der alten und neuen /var/cache/edb/esearchdb.py betrachtet. Die Felder pkgname, pkg und vinstalled sind immer identisch, die Felder masked und vavail unterscheiden sich jedesmal, wenn ein Paket in /etc/portage/package.* (de)maskiert wurde.

 

Oh, shit. Das hab ich total vergessen. Hab jetzt grad mal versucht, das auf die schnelle zu lösen, was aber nicht so einfach ist. Das Problem ist, dass es erstmal verschiedene Dateien gibt:

package.mask

package.unmask

package.keywords (Muss genauso beachtet werden)

package.provided (Muss auch beachtet werden, für die installierte Version)

Ich hab jetzt 2 Möglichkeiten: Entweder ich bastel selbst was, dass überprüft, ob das aktuelle Paket, das indiziert wird, in einer der Dateien vorkommt, und die entsprechenden Änderungen vornimmt oder ich finde in der 72000 Zeilen portage.py eine Funktion, die mir dabei hilft, und die nicht wie viele Funktionen aus der Portage API so langsam ist, dass es den Indexing-Prozess wieder total verlangsamt.

 *Quote:*   

> Und dann hab ich noch den seltenen Fall gefunden, in dem ein Paket installiert, in dieser Version aber nicht mehr im Portage-Tree vorhanden ist

 

Am besten wirds sein, ich hol mir die Information über das installierte Paket aus /var/db/pkg, oder doch wieder per Portage API.

Auf jeden Fall vielen Dank für deine Arbeit, ich hoff mal, dass ich das irgendwie hinbekomme, und dass wir nicht wieder zurück müssen, zur alten Methode.

David

PS: portage.settings.pmaskdict sieht schonmal sehr vielversprechend aus

----------

