# Hey gentoo hat sich gespaltet!

## magir

Unglaublich, ich finde's schade!

aber macht euch lieber selbst ein Bild davon!

http://www.zynot.org/

Was hält ihr davon?

So ist es halt mit Open-Source, alles bleibt am halbweg liegen!!!

Vielleicht ist es auch gut so!

----------

## ts77

wo ist das problem?

die können doch mit ihrem fork ihrer wege gehen.

nichts bleibt halbweg liegen, gentoo geht weiter (offensichtlich).

----------

## phelan

Ich denke, dass der Fork vorallem gutes mit sich bringt:

Der Ehrgeiz der Entwickler wird durch die gegenseitige Konkurenz angespornt. Wenn es noch eine zweite Plattform gibt, werden vielleicht mehr Neuerungen ausprobiert, von welchen man sich ja dann die gewünschten rauspicken kann!

----------

## Beforegod

Aber dieser Ehrgeiz kann schnell in Fanatismus enden, wenn jeder für "sein Projekt" alles tut und das andere dann nicht mehr akzeptiert usw.  Es wird bald so manchem Flame-War dazu geben, aber egal.

Meine Sorge liegt darin, das evt. wirklich gute Neuerungen nicht für das jeweilige andere Projekt zugute kommt.

Aber warten wir mal die ENtwicklung ab.

----------

## bonsaikitten

Nachdem Gentoo alle interessanten Entwicklungen einfach assimiliert, mache ich mir kaum Sorgen ... sollte der Fork wirklich neue Entwicklungen mit sich bringen, wirds einfach nach Gentoo zurueckportiert.   :Very Happy: 

----------

## Genone

Das einzige was mir Sorgen machen würde wäre, wenn in grösserem Umfang Resourcen (v.a. Entwickler, aber auch Hardware, User, ...) von Gentoo nach Zynot gehen. Dann müsste man sich allerdings fragen, ob Zynot nicht besser ist als Gentoo. Momentan sieht das zum Glück noch nicht so aus, allerdings sind einige der Ideen von Zynot für portage (bzw. deren neues Paket Management) recht interessant. Mal sehen wie sich das weiterentwickelt.

----------

## JensZ

Hab't ihr euch mal die Gründe für die Aufspaltung durchgelesen?

Ich will mir hier kein Urteil erlauben, aber sollte das wirklich so gelaufen

sein ist es eine Sauerei. Wie dem auch sei, hab ich das Gefühl, das

die Zyklen in denen neue Updates im Portage erscheinen merklich

größer geworden sind (kann natürlich auch sein das ich mich vertue,

oder einfach nur die falschen Packete). Das soll keine Anklage an

die Entwickler sein, es ist ein große Leistung überhaupt ein packet zu

betreuen, zumal die meißten Entwickler mehr als ein Packet betreuen.

Es mag aber ein Indiz dafür sein, das hinter den Kulissen ganz schön

was los ist...

----------

## DieMumiee

Am Ende des Artikels ist ein Link zu einem zweiten "Fork". Wobei es sich hierber nur um einen portage fork handelt, wenn überhaupt. Dieser Weggang von Geert Beven hat mich deutlich stärker erschreckt. Die Art wie D.Robbins über portage2 entschieden hat, hat mir überhaupt nicht gefallen. Eine Skriptsprache für so etwas wichtiges wie dem Paketmanager gegenüber einer compilierten Sprache vorzuziehen sollte viel genauer begründet werden. 

    Ich wäre wirklich froh wenn es ein C++ emerge gäbe, weil es einfach schneller wäre, und die Entwickler den Compiler als weitere Korrekturinstanz hätten. Python bietet eigentlich nur den Vorteil dass es leichter zu lernen ist, und die üblichen Nachteile einer Skriptsprache. Dass in C++ viele Dinge von Grund auf entwickelt werden müssten die in Python schon vorhanden sind sollte die Entwickler bei der Größe der Community eigentlich nicht abschrecken. Ich nehme an dass D.Robbins C++ abgelehnt hat weil er selbst am portage programmieren möchte, und damit nicht umgehen kann.

Aber sollte das zum Aufgabenbereich eines Projektleiters gehören?

----------

## MasterOfMagic

ja das stört mich auch irgendwie. ich muss bei gentoo ja python am rechner haben, damit ich überhaupt was installieren kann. hätte man diese sachen (wenn schon in einer interpretersprache) nicht auch gleich in bash realisieren können oder hab ich da jetzt was übersehen. ich meine ne shell hat so ziemlich jeder auf seinem linuxrechner aber python ist ja nun nicht unbedingt das was man unbedingt auf seinem rechner haben will. 

mfg

masterofmagic

----------

## Beforegod

Dei Gründe warum es diese Spaltung gibt sind heiss diskutiert und leider sind auch viele Unwahrheiten dazu gekommen. Leider kenne ich nicht die Wahrheit (wie viele andere auch nicht), aber ich bin der Meinung das man sich darüber nicht das Maul zerfetzen muss (tschuldigt diesen ordinären Ton). Wenn es jemanden nicht gefällt wie das System verwaltet wird, bitteschön... entweder selber was machen, oder bei dem Zweit Projekt (das sein Hauptaugenmerk auf kleine Systeme legt!) mitwirken. 

Und wenn die Entwickler (oder D. Robbins) der Meinung ist das Python einfach besser ist für emerge (ob es nun stimmt oder nicht!) dann ist das als Projektleiter nunmal sein letztes Wort.

Es gibt genug alternative zu Gentoo und von meiner Seite kann ich weder über Python klagen, noch über die Politik die D. Robbins vertritt bzw. durchführt.

----------

## haceye

Hi,

Ich sehe das auch nicht so schwarz. Ich denke eher, dass durch die Konkurrenz (wenn überhaupt, beide verfolgen ja in gewisser Weise auch andere Ziele...) beide Distributionen besser werden.

Zu Python: Ich persönlich sehe da auch keinen Nachteil. Der einzigste Vorteil von C++ besteht meiner Meinung nach darin, dass Portage wirklich schneller wäre, aber für Python spricht, dass es leichter zu erlernen ist, meisst viel weniger Code erfordert, da es praktisch für alles schon Module/Funktionen/... gibt.

Ausserdem ist Portage als Python Script leicht erweiterbar. Ein "import portage" genügt, und man kann ganz schnell eigene, auf Portage aufbauende Scripte schreiben.

Finde es allerdings auch etwas komisch, dass keine genauen Gründe dafür genannt wurden.

Ich mag auf jeden Fall gentoo (und damit Portage) so wie es ist.

David

----------

## kopfarzt

Ich glaube eigentlich nicht, dass eine Scriptsprache in diesem Fall viel langsamer als C++ ist. Schliesslich handelt es sich nicht um rechenintensive Tasks mit astronomischen Schleifen (wie etwa bei einem Raytracer) sondern um logische Tasks. Es wird vermutlich viel mit Listen, Dictionaries und Strings gearbeitet und eine Menge Textfiles geparsed, was innerhalb von Python sowieso "native" (also hochoptimiert in C) abläuft. Man erspart sich das gesamte Speichermanagement wo man bekanntlich einiges an Fehlern produzieren kann, sowohl Leaks, als auch suboptimale Nutzung usw. Wer nicht glaubt, daß eine Scriptsprache hier genauso schnell, wenn nicht oft sogar schneller ist (in der Praxis), soll mal nach Benchmarkvergleichen zwischen C++ und z.B. Java suchen (da gabs mal welche am Netz).

Aber neben der Geschwindigkeit ist meiner Meinung nach ein wichtiger Punkt für Python bzw. eine Scriptsprache die Plattformunabhängigkeit, da die meisten Python Module auf jeder Plattform gleich aussehen.

Das ganze in Shell zu programmieren wäre wahrscheinlich machbar, aber halte ich persönlich für extrem mühsam und unübersichtlich (z.B. Datenstrukturen, Kapselung?).

Ich finde die Entscheidung für eine Scriptsprache richtig und bin auch froh, daß es sich um Python handelt, weil das einfach eine klare und schöne Sprache ist. Mit einer der Gründe warum ich Gentoo so nett finde.

kopfarzt

----------

## haceye

Hi,

Stimme vollkommen mit dir überein.

Ich glaube auch, dass Portage oft nicht wegen Python langsam ist, sondern weil z.B. der Portage-Tree, bzw. der /var/db/pkg-Tree als Verzeichnissbaum angeordnet ist. Mit einer Datenbank im Hintergrund würde das bestimmt auch etwas schneller laufen, aber mir gefällt es so viel besser, da es übersichtlicher ist, und man auch gut damit arbeiten kann (man braucht nicht SQL o.ä. zu lernen).

 *kopfarzt wrote:*   

> Wer nicht glaubt, daß eine Scriptsprache hier genauso schnell, wenn nicht oft sogar schneller ist (in der Praxis), soll mal nach Benchmarkvergleichen zwischen C++ und z.B. Java suchen (da gabs mal welche am Netz).

 

Hmmm... Java ist doch keine Scriptsprache?!

ciao David

----------

## JensZ

vielleicht gibt's in der neuen Distri ja ne Lösung die besser ist, mal sehen

was die so auf die Beine stellen, wenn's besser ist kann man das ja in

Gentoo assimiliere ...

----------

## kopfarzt

 *haceye wrote:*   

> 
> 
> Hmmm... Java ist doch keine Scriptsprache?!
> 
> 

 

*grins* was ist denn eine Scriptsprache?!  :Smile:  Habe mich in diesem Fall der hier verwendeten Nomenklatur angepaßt. Python ist (wie Java auch) eine interpretierte Byte-Code Sprache. *.pyc entspricht *.class also auch hier echt vergleichbar.

kopfarzt

PS: mich würde allerdings interessieren, ob der Begriff Scriptsprache vielleicht doch noch eine tiefere Bedeutung hat oder einfach für alle interpretierten Sprachen gilt, oder etwa nur für die, die keinen Byte-Code erzeugen...?

----------

## haceye

Hi,

Naja, der Unterschied besteht meiner Meinung nach darin, dass Java kompiliert werden muss, und Python nicht. Das ist bei Python nur eine Option, gibts bei Perl z.B. auch.

Deiner Definition nach wäre dann ja C# auch eine Scriptsprache.

ciao David

----------

## beejay

Das Problem liegt daran, dass Portage bis zu 300 MB (!) an Metadaten mitverwalten muss. Metadaten sind die ganzen Datenabfälle, die beim Auflösen von Abhängigkeiten benötigt werden bzw. entstehen. Diese müssen jedesmal neu berechnet werden, woraus ein Aufwand von vielen kleinen Zugriffen entsteht, die zusammengenommen aber riesig gross sind. 

Zumindest durch einen Kern in C (oder C++, denn der Portage-Code hat ja Klassen implementiert) könnte sich einiges an Geschwindigkeit herausholen lassen. Sinnvoller wäre es aber, die Metadaten anders zu verwalten - wie schon erwähnt z.B. über eine Datenbank. Dann würde sich aber wieder die Frage stellen: "Ich brauche eine installierte Skriptsprache und eine Datenbank für mein Paketsystem - was ist das?". Jede erdenkbare Datenbank hat selbst auch noch Abhängigkeiten, und eine Datenbankmaschine in Python zu entwickeln würde das ganze zwar eleganter machen, es aber genau so schnell halten. Es wäre im Endeffekt genauso, als bräuchte man eine eigene Tankstelle und eine Garage, nur um einen Rasenmäher besitzen zu können - schlechtes Beispiel, aber ich denke es verdeutlicht gut den Sachverhalt.

Mit gutem C/C++-Code könnte man dieses Manko schon ausräumen.

----------

## Pietschy

Da ich nichts vom programmieren verstehe (ich meine selbst meine scripte sind mies)  :Wink:  nehme ich das mal so hin.

Die Datenbank klingt trotzdem gut, es gibt doch sicher einmöglichkeit sowas als zusatzfeature das sinnvoll aber nicht undbedingt notwendig ist in gentoo einzubauen, so wie ccache.

Ronny

Nachtrag: Ups ist das oT

----------

## haceye

Hi

Naja, das mal "so schnell" als Zusatzfeature zu implementieren geht glaube ich nicht. Um das dann sinnvoll zu nutzen müsste man z.B. die ebuilds in eine Tabelle schreiben, und unterschiedliche Felder wie HOMEPAGE, DESCRIPTION, ... usw. haben. Komplexere Sachen wie (R)DEPEND müssten evtl. schon wieder in eine neue Tabelle. Ich weiß nicht wie das mit dem ganzen Caches usw. aussieht.

Allerdings meine ich schonmal etw. ähnliches im "Portage & Programming" Forum gesehen zu haben. Vielleicht wird ja doch noch was draus.

Mir ist Portage - so wie es ist - schnell genug.

Ach und wo wir gerade beim Thema (oder eigentlich nicht) sind, hier eine kleine Portage-Erweiterung von mir. Und zwar handelt es sich dabei um ein schnelleres emerge search (Eine der Aufgaben, bei der Portage wirklich sehr langsam ist).

Mein Script hat fast die gleiche ausgabe wie emerge search (bis auf "Size of downloaded files" und ein paar Kleinigkeiten), ist aber auf meinem Rechner zw. 40 und 1000 mal schneller.

Ok, das funktioniert natürlich nur mit einem kleinen Trick... Und zwar einem Index. (Ähnliches Prinzip wie bei locate (updatedb))

wer sich das ganze mal anschauen will, kann sich die drei Scripte hier zusammenkopieren:

eupdatedb - Shellscript (chmod +x eupdatedb) um das Pythonscript aufzurufen.

```
#!/bin/bash

start=`date +"%s"`

python eupdatedb.py > db.py

# compile python file

python -c 'import db'

rm db.py

stop=`date +"%s"`

echo Updated Database in $(($stop - $start)) seconds

```

eupdatedb.py - Pythonscript um den Index zu generieren, Warnung, ganz schlechter Code - bitte nicht lesen  :Wink: 

```
#!/usr/bin/env python2.2

import portage

from output import red, darkgreen, green, bold

import sys

vartree = portage.vartree()

def version(pkg):

    # from emerge

    if len(pkg) > 1:

        parts = portage.catpkgsplit(pkg)

        if parts == None:

            return red("[ Not installed ]")

        if parts[3] != 'r0':

            version = parts[2]+ "-" + parts[3]

        else:

            version = parts[2]

        return version

    else:

        return ""

print "db = {"

for pkg in portage.portdb.cp_all():

    masked = ""

    pkgv = portage.portdb.xmatch("bestmatch-visible", pkg)

    if not pkgv:

        pkgv = portage.best(portage.portdb.xmatch("match-all", pkg))

        masked = red(" [ Masked ]")

    try:

        if len(pkgv) > 1:

            homepage, description = portage.portdb.aux_get(pkgv, ["HOMEPAGE", "DESCRIPTION"])

        else:

            homepage, description = ["", ""]

    except KeyError:

        homepage, description = ["", ""]

    str =  green("*") + "  " + bold(pkg) + masked + "\n"

    str += "      " + darkgreen("Latest version available: ") + version(pkgv) + "\n"

    str += "      " + darkgreen("Latest version installed: ") + version(vartree.dep_bestmatch(pkg)) + "\n"

    str += "      " + darkgreen("Homepage:    ") + homepage + "\n"

    str += "      " + darkgreen("Description: ") + description + "\n"

    print repr(pkg) + ": " + repr(str) + ","

print "}"

```

esearch - Der Ersatz für emerge search, kleines Pythonscript (chmod +x)

```
#!/usr/bin/env python2.2

from db import db

from sys import argv

import re

pattern = re.compile(argv[1], re.IGNORECASE)

for (key, str) in db.items():

    if pattern.search(key):

        print str

```

Und so wird das ganze benutzt:

```

shark@gentoo esearch $ # Alle Dateien zusammenbasteln und in einem Ordner speichern

shark@gentoo esearch $ chmod +x esearch

shark@gentoo esearch $ chmod +x eupdatedb

shark@gentoo esearch $ ./eupdatedb

Updated Database in 16 seconds

shark@gentoo esearch $ esearch kdebase

*  kde-base/kdebase

      Latest version available: 3.1.2

      Latest version installed: 3.1.2

      Homepage:    http://www.kde.org/

      Description: KDE base packages: the desktop, panel, window manager, konqueror...

```

ciao David

----------

## magir

Da kann ich nur zurstimmen.

Datenbank ist nicht nur cool, ist auch sehr funktional und schnell.

Deswegen wird auch nächstes Windows auf einer DB stat file-system basieren. Ich meine, das File-System ist dann eine grosse DBMS. 

Datenbank ist leicht zu pflegen und leicht erweiterbar. Außerdem bekommt man viel Funktionalität, so zu  sagen, umsonst, sprich Abhängigkeiten wäre zum beispiel eine einfache "referenielle intergrität". Man könnte aber komplete gentoo-configuration in einer DB unterbrigen. Stellt euch nur eine Tabelle mit USE-Flags vor. Ist es nicht cool immer alle USE-Flags auf einen Blick zu haben!? Man könnte diese dann noch mit Zeitstempel versehen und schon kann man einfach für jede Version richtige USE-Flags rauskriegen. Sollche Beispiele kann man sehr weit fortsetzen... So was benötigt natürlich guter Planung, wäre aber zukunftsweisend!!! Was meint Ihr?

----------

## Pietschy

jaja so isser der haceye  :Wink: 

Redet mir meine DB madig und bringt mir gleichzeit ein Geschenk  :Smile: 

Genau sowas habe ich gesucht eine schnelle Suche, dankeschön.

Und da wir gerade so schön off Topic sind, beejay ist es möglich auf gentoo.de eine script Datenbank (schonwieder dieses Wort) einzurichten, wo alle möglichen "werke" eingestellt werden könnten. Ich habe schon sehr viel gute scripte hier im Forum in vergessenheit geraten sehen, auf getnoo.de wären sie immer schnell verfügbar und könnte sich zu wahren fundgrube entwickeln.

Ronny

----------

## beejay

 *Pietschy wrote:*   

> jaja so isser der haceye 
> 
> Und da wir gerade so schön off Topic sind, beejay ist es möglich auf gentoo.de eine script Datenbank (schonwieder dieses Wort) einzurichten, wo alle möglichen "werke" eingestellt werden könnten. Ich habe schon sehr viel gute scripte hier im Forum in vergessenheit geraten sehen, auf getnoo.de wären sie immer schnell verfügbar und könnte sich zu wahren fundgrube entwickeln.
> 
> Ronny

 

Ich werde das mal abklären, sollte aber kein Problem sein - vorerst aber nur als Text, nicht zum Download (das sollte sich aber u.U. auch verwirklichen lassen)

----------

## JensZ

Naja eine Datenbank ist immer so eine Sache, wer schonmal ne rpm

distri hatte der's die Datenbank zerschossen hat weiß was ich meine.

Wär halt zu überlegen, was man wie löst, grundsätzlich ist ne Datenbank

zwar am besten, aber ich denke keiner will in den rpm like Sumpf

absacken. Und das gesammt Emerge auf C++ umzustellen halt ich für

eine sehr gute Idee, da dürfte noch einige Geschwindigkeitsvorteile

möglich ein. Außerdem wäre es dann leichter verschiedene UI's zu bauen.

----------

## lonF

das RPMdb prob kenne ich zur genüge daher find ich eine db nicht so toll.

Hat aber wie gesagt alles Vor- und Nachteile.

Interessant ist das mit den UI's. Stellt sich nur die Frage will das überhaupt jemand. Ich ziehe die Shell vor hab mit UI's (hauptsächlich unter RedHat) schon manches böses erwachen gehabt. Hab immer wieder alles von Hand gemacht. Und bin damit immer besser gefahren.

Bin nun auch kein Profi was programmieren angeht. Aber ich denke mit Regulären Ausdrücken wie Sie in jeder vernünftigen "Scriptsprache" existieren, hat man wesentlich schneller TextFiles geparsed. Oder???

Wenn ich falsch liege korrigiert mich.

----------

## Pietschy

Ok das für und wieder einer Datenbank, kann wohl in einer sehr langen diskussion enden (hab aber auch noch keine Ehrfahrungen mit einer abgeschossenen rpmDB, (jahrelang SuSE )). 

Ich denke aber das es im Portage einiges an geschwindigkeit zu verbessern gibt, zB das Script 5 Posts oben drüber. Hey man ich liebe es.  :Smile: 

Und im Grunde ist es nichts weiter als eine Abbild des Portagebaum in einer Datenbank. (wenn ich mich nicht verlesen habe (habe ich schon erwähnt, das mein scriptisch nicht so toll ist?))

Emerge auf C++ umstellen, ist glaube ich nicht das was die Entwickler im Sinn haben.

Ronny

----------

## haceye

Hi,

 *Pietschy wrote:*   

> Ich denke aber das es im Portage einiges an geschwindigkeit zu verbessern gibt, zB das Script 5 Posts oben drüber. Hey man ich liebe es. 

 

Danke für das Lob. Ich werde das Script noch ein wenig weiterentwickeln:

* "emerge -s" - kompatibilität

* Suche auch in Description (wie emerge -S)

* Index schneller erstellen?

* 2 Bugs entfernen  :Wink: 

werde es dann irgendwann hier posten.

David

----------

## Genone

Ok, wie der Zufall so will hab ich gestern auch grade an einem Suchskript gebastelt. Die Ausgabe ist zwar primitiv (enthält u.a. keine Versionsnummern, da nur die letzte Version indiziert wird), versteht keine eclasses, das Updaten der Indexdatei dauert zu lange und es könnte noch Probleme mit bestimmten Zeichen in DESCRIPTION geben, die dann meine grep Expressions verwirren, dafür ist es extrem schnell (die meiste Zeit geht für die Ausgabe drauf   :Laughing: ), reiner Bash Code, fehlertolerant (ich benutz z.B. RSYNC_EXCLUDE), per Patch integriert in emerge und IMO benutzerfreundlich.

Der integriert die --fastsearch Option in emerge um das Skript zu benutzen und das feastsearch Feature in make.conf um den Index bei jedem emerge sync upzudaten (nicht zu empfehlen wenn man emerge sync immer manuell macht). Um den Patch zu benutzen muss das Skript als /usr/lib/portage/bin/fastsearch abgespeichert sein (oder man ändert den Patch um), die Option taucht aber nicht bei emerge --help auf, dafür müsste man noch emergehelp.py ändern. 

Skript und Patch gibts unter http://gentoo.devel-net.org/download/, ich poste die auch mal hier (s.u.), der Patch könnte aber bei copy+paste Probleme mit den Tabs machen.

Was die Performanceprobleme von portage angeht, ein grosses Problem ist die Startzeit. Ich hab mal Messungen angestellt mit meinem Skript in emerge und der normalen Suche von portage, der Unterschied ist ca. 2 Sekunden. allerdings macht es ca. 5 Sekunden Unterschied zwischen meinem Skript standalone und in emerge integriert (alle Messungen auf meinem P2 233 Server). Bei einer Suche in DESCRIPTION macht sich das Fehlen eines Indexes stärker bemerkbar, da braucht portage 1-2 Minuten, mein Skript ca. 1 Sekunde. Diese Probleme sind bekannt und carpaski (der portage Maintainer) arbeitet auch dadran, der Metadaten Cache wird z.B. bald in einer DB abgelegt (nix SQL, Berkley DB oder so). Es gibt IIRC auf http://breakmygentoo.net ein Projekt um PostgreSQL als portage backend zu benutzen, könnte interessant sein das mal mit dem aktuellen Portage zu vergleichen (Performance mässig).

Langfristig denke ich wird man nicht um um ein Rewrite von portage herumkommen (ob jetzt in Python oder sonst irgendeiner Sparche), da der

aktuelle Ansatz IMO zu monolitisch ist um in Zukunft wartbar zu sein (das verursacht u.a. auch die langen Startzeiten von emerge). Meine Idee ist ein Kern, der verschiedene Front- und Backends als Module realisiert, so dass der User sich aussuchen kann, ob er eine schnelle SQL Datenbank oder z.B. das jetzige (langsame) System als Backend haben will. Wenn man noch weiter geht könnte man sogar verschiedene Backends für Unterschiedliche Daten benutzen, z.B. Ebuilds im Dateisystem und Metadaten (Name, Description, Maintainer, ...) in einer DB, aber bis dahin muss noch sehr viel Code geschrieben werden.

Ok, hier jetzt das Suchskript:

fastsearch:

```
#!/bin/bash

# a lightning fast search script for the portage tree

# (C) 2003 Marius Mauch

source /etc/make.conf         # to get PORTDIR and PORTDIR_OVERLAY

SEARCH_DB=/var/cache/edb/fastsearch_db   # the name of the database file

PROG_NAME=$(basename $0)      # the name of this script for use in help messages

# print a usage message

print_help()

{

   echo "Usage:"

   echo "${PROG_NAME} -h | --help | -u | --update | <mode-option> <pattern> <grep-options>"

   echo -e "\t-h | --help:         print this usage message"

   echo -e "\t-u | --update:       (re-)create the search database"

   echo "mode-option is one of:"

   echo -e "\t-d | --description:  search in descriptions"

   echo -e "\t-n | --name:         search in package names"

   echo -e "\t-l | --long-desc:    search in long descriptions"

   echo -e "\t-a | --all:       search in all fields"

   echo 'pattern is a grep regular expression to search for (^ and $ might not work as expected)'

   echo "grep-option is one or more options for grep to manipulate the search"

}

# imports the names and descriptions of all packages in the given directory 

# into the database.

#

# $1: directory to import

import_category()

{

   if [ -d "${1}" ]; then

      echo "    reading category ${1} ..."

      for P in "${1}"/*; do

         EBUILD=$(ls -v ${P}/*.ebuild 2> /dev/null | tail -1)

         if [ ${EBUILD} ]; then

            # get only the variable assignment and strip the quotes,

            # might cause problems if the description itself contains quotes

            DESCRIPTION=$(grep DESCRIPTION\= ${EBUILD} | cut -d\= -f 2 | cut -d\" -f 2)

            printf "%-30s%s\n" "${P}::" "${DESCRIPTION}" >> "${SEARCH_DB}.new"

         else

            echo "        No ebuilds for package ${P}, skipping"

         fi

      done

   else

      # some categories might have entries in the categories file

      # but no corresponding directory caused by RSYNC_EXCLUDE or other

      # user modifications

      echo "    No directory for category ${1}, skipping"

   fi

}

# the main script starts here

case "$1" in

   -h | --help)

      print_help

      exit 0

      ;;

   -n | --name)

      MODE=SEARCH

      FIELD=NAME

      ;;

   -d | --description)

      MODE=SEARCH

      FIELD=DESC

      ;;

   -s | --search)

      MODE=SEARCH

      FIELD=ALL

      ;;

   -l | --long)

      # reserved for future versions

      echo "not implemented yet"

      exit 3

      ;;

   -u | --update)

      MODE=UPDATE

      ;;

   -*)

      echo "I don't know this option: $1"

      print_help

      exit 1

      ;;

   *)

      if [ -z "${1}" ]; then

         echo "I need at least one option"

         print_help

         exit 1

      else

         echo "No mode option given, assuming name search"

         MODE=SEARCH

         FIELD=NAME

         set - "${1}" "${1}"   # set $2=$1

      fi

      ;;

esac

if [ "$MODE" == "SEARCH" -a -z "$2" ]; then

   echo "I need a pattern to search for"

   print_help

   exit 1

fi

if [ "${MODE}" == "UPDATE" ]; then

   [ -d $(dirname "${SEARCH_DB}") ] || mkdir -p $(dirname "${SEARCH_DB}")

   echo "Updating database ..."

   rm -f "${SEARCH_DB}.new"

   

   echo "importing packages from ${PORTDIR} ..."

   cd "${PORTDIR}"

   for C in $(grep -v packages profiles/categories); do

      import_category "${C}"

   done

   

   echo "importing packages from ${PORTDIR_OVERLAY} ..."

   cd "${PORTDIR_OVERLAY}"

   for C in *; do

      import_category "${C}"

   done

   mv -f "${SEARCH_DB}.new" "${SEARCH_DB}"

   echo "Finished updating"

   exit

fi

if [ ! -f "${SEARCH_DB}" ]; then

   echo "no search database found, you should create it with \"${PROG_NAME} --update\""

   echo "see \"${PROG_NAME} --help\" for a description of all options"

   exit 2

fi

PATTERN=$2

shift

shift

GREP_OPTIONS="${GREP_OPTIONS} $*"

case "${FIELD}" in

   NAME)

      grep ${GREP_OPTIONS} "${PATTERN/^//}.*::" "${SEARCH_DB}"

      ;;

   DESC)

      grep ${GREP_OPTIONS} "::.*${PATTERN}" "${SEARCH_DB}"

      ;;

   ALL)

      grep ${GREP_OPTIONS} "${PATTERN}" "${SEARCH_DB}"

      ;;

esac

[ "$?" != "0" ] && echo "no matching entries found"
```

emerge Patch für portage 2.0.48-r1:

```
--- emerge.old   2003-06-08 13:20:46.000000000 +0200

+++ emerge.new   2003-07-08 23:24:32.000000000 +0200

@@ -40,6 +40,7 @@

 "--onlydeps",     "--pretend",

 "--quiet",        "--resume",

 "--searchdesc",   "--selective",

+"--fastsearch",

 "--skipfirst",

 "--update",       "--upgradeonly",

 "--usepkg",       "--usepkgonly",

@@ -156,6 +157,9 @@

 # Also allow -S to invoke search action (-sS)

 if ("--searchdesc" in myopts) and (not myaction):

    myaction = "search"

+# --fastsearch also implies search

+if ("--searchdesc" in myopts) and (not myaction):

+   myaction = "search"

 

 # Also allow -K to apply --usepkg/-k

 if ("--usepkgonly" in myopts) and not ("--usepkg" in myopts):

@@ -1683,6 +1687,9 @@

       portage.spawn("chmod -R g+rw "+portage.dbcachedir, free=1)

       sys.stdout.write("\b\b  ...done!\n\n")

       sys.stdout.flush()

+   if "fastsearch" in portage.features:

+      print "\n>>> Building fastsearch database ..."

+      portage.spawn("/usr/lib/portage/bin/fastsearch -u", free=1)

 

    portage.portageexit()

    reload(portage)

@@ -1739,15 +1746,22 @@

    if not myfiles:

       print "emerge: no search terms provided."

    else:

-      

-      searchinstance = search()

-      for mysearch in myfiles:

-         try:

-            searchinstance.execute(mysearch)

-         except re.error, comment:

-            print "\n!!! Regular expression error in \"%s\": %s" % ( mysearch, comment )

-            sys.exit(1)

-         searchinstance.output()

+      if "--fastsearch" in myopts or "fastsearch" in portage.features:

+         for mysearch in myfiles:

+            if "--searchdesc" in myopts:

+               mymode = "-d "

+            else:

+               mymode = "-n "

+            portage.spawn("/usr/lib/portage/bin/fastsearch " + mymode + mysearch + " -i")

+      else:

+         searchinstance = search()

+         for mysearch in myfiles:

+            try:

+               searchinstance.execute(mysearch)

+            except re.error, comment:

+               print "\n!!! Regular expression error in \"%s\": %s" % ( mysearch, comment )

+               sys.exit(1)

+            searchinstance.output()

 elif "inject"==myaction:

    if not myfiles:

       print "emerge: please specify at least one cat/pkg-ver to inject."
```

So, auch das längste Posting muss mal zu Ende sein.

----------

## aias

kennt einer das programm kdeportage?

funktioniert das vom ansatz her genauso wie die obigen suchscripte?

----------

## dertobi123

Nö, ist "nur" nen grafischer Aufsatz für's Portage, aber wer braucht sowas schon ....

Gruß Tobias

----------

## CHerzog

 *dertobi123 wrote:*   

> Nö, ist "nur" nen grafischer Aufsatz für's Portage, aber wer braucht sowas schon ....

 

Ich nutze das um einfach mal den Portagetree zu durchstöbern. 

Vorteile:

KDEPortage ist nett, da es den Baum anzeigt und mir sofort alle wichtigen Informationen zum Paket anzeigt. 

Ein Klick und ich kann mir gleich die Homepage ansehen.

Ich sehe die Histori, das Changelog, etc - wie gesagt: Alles auf einen Blick.

Um Programme zu installieren nutze ich dann aber wieder die Shell. Ist mir einfach sicherer.

Christian

----------

## dertobi123

 *Quote:*   

> Um Programme zu installieren nutze ich dann aber wieder die Shell. Ist mir einfach sicherer. 

 

Genau das ist das Problem; zumindest bei meinen bisherigen Versuchen gewesen (Sind schon ne Weile her)  ... Das Ding läuft einfach nicht stabil.

Gruß Tobias

----------

