# Portage - Und was Debian besser macht

## hoschi

Hallo,

warum lädt Portage eigentlich immer die ganzen Ebuilds runter, wieso reicht es nicht aus einfach nur:

Paketname, Version, Beschreibung, Abhängigkeiten, Architektur und Größe zu  Speichern?

Folgende Vorteile:

- Datenmenge sinkt drastisch, weniger Kosten auf Server-Seite

- Geschwindigkeitszunahme, ein Sync dauert wesentlich kürzer

- Portage Arbeitsgeschwindigkeit müsste dadurch zudem drastisch gesteigert werden, wenn ich nur daran denke wie schnell mein Debian-Server wusste was er alles zu Updaten hatte - und das bei einem Woody 3.0 auf Testing...

Oder was ich sagen will, die Arbeitsgeschwindigkeit von Portage ist absolut inakzeptabel, besonders wenn das System schon lange "exestiert", da löscht man ja bald leicht den ganzen Portage-Tree und läd alles neu, das dürfte bei mir bald schneller gehen  :Sad: 

Ich will damit vernünftige Kritik üben, und Anregungen schaffen - da mir der jetzige Zustand nicht mehr gefällt  :Smile: 

Hoschi

<edit> Schreibfehler sind Eigentum des Autors...Danke, war wohl gerade die Umgebungsvariable "hirn_off" gesetzt  :Wink: 

----------

## _hephaistos_

hi

 *hoschi wrote:*   

> Oder was ich sagen will, die Arbeitsgeschwindigkeit von Portage ist absolut unakzeptal, besonders wenn das System schon lange "exestiert", da läuscht man ja bald leicht den ganzen Portage-Tree und läd alles neu, das dürfte bei mir bald schneller gehen 

 

1) the word is "inakzeptabel"  :Smile: 

2) ich hab diese woche auch schon manchmal überlegt, was man da tun könnte

 portage is mom. wirklich sehr langsam

 portage is mom. bei mir ca. 500 MB

was ich mir ev. gedacht hab: das mit den ebuilds ist eh eine SEHR gute sache. aber ev. sollte portage auf einem zentralen server online bleiben.

sämtliche suchen etc. müssten dann halt auch online erfolgen.

aber

1) es muss nicht mehr jeder syncen == trafficersparnis

2) es werden nur jene ebuilds heruntergeladen, die auch effektiv installiert werden...

usw.

was ist nachteilig an dieser "online" lösung? (mir ist klar, dass man dann nicht suchen kann  :Smile: )

ev. lädt portage die ebuilds herunter und löscht diese dann auch gleich wieder.

man könnte ja eine art "wrapper" für portage schreiben.

dh: "emerge" lädt die benötigten ebuilds für portage nach /usr/portage/whatever und portage kann dann "ganz normal" weitermachen...

ciao

----------

## hoschi

Mhh, so sieht es ja im Grunde wahrscheinlich bei Debian aus, ich kenne mich da in den Interna nicht so aus (ich dache es wäre eher wie in meinem ersten Post dargestellt), war nur ca. 3 Wochen im Besitzt des Debian-Servers  :Very Happy: 

Man wäre natürlich, sofern man mit Portage arbeiten will, und nicht selber Hand anlegt, etwas mehr Abhängig von diesem Server. Aber diese Rolle würde ja sicher von den ganzen Rsync-Servern übernommen werden, also würde sich da nichts ändern.

Ich muss zugeben, kein Anhänger des sogenannten Thin-Client-Konzeptes zu sein, ich möchte nicht zu viel Abhänigkeiten von Servern heraufbeschwören, so lange es ein Standalone-Desktop ist.

Gibt es den schon Bestrebungen von Entwicklerseite?

Wie du schon angedeutet hast, die Modifikationen müssten letztlich gar nicht mal so groß ausfallen.

----------

## STiGMaTa_ch

 *hoschi wrote:*   

> warum lädt Portage eigentlich immer die ganzen Ebuilds runter, wieso reicht es nicht aus einfach nur:
> 
> Paketname, Version, Beschreibung, Abhängigkeiten, Architektur und Größe zu  Speichern?

 

Weil es in den Emerge Files alle Anweisungen drinn hat WIE das Paket zu kompilieren/installieren ist und dort auch abhängigkeiten drinn sind  :Rolling Eyes:   :Question:   :Exclamation: 

*Ich weiss es nicht genau!*

 *Quote:*   

> Folgende Vorteile:
> 
> - Datenmenge sinkt drastisch, weniger Kosten auf Server-Seite
> 
> - Geschwindigkeitszunahme, ein Sync dauert wesentlich kürzer
> ...

 

Es gibt da eine Möglichkeit bei einem "emerge --sync" nur noch gewisse Ebuilds einzubeziehen, bzw. nicht benötigte auszuschliessen...

Siehe diesen Link

Ausserdem weiss ich nicht wass du für ein Problem mit der Arbeitsgeschwindigkeit hast. Ein emerge PAKETNAME legt bei mir SOFORT los  :Smile: .

Falls du die Geschwindigkeit jedoch auf die "Suche" in den Ebuilds beziehst, muss ich dir zustimmen. Dies hat jedoch den einfachen Grund, dass emerge jedesmal durch alle ebuilds rattert um nach dem gesuchten zu fahnden. Hilfreich wäre hier ein Index. Dieser müsste einmal aufgebaut werden und nicht jedesmal "on the fly" erstellt werden.

Aber auch dieses Problem wird mit dem Paket  "esearch" entschärft

```
emerge -s esearch
```

Sonst noch Fragen Kienzle  :Very Happy: 

Edit: Musste das mal entschärfen. Las sich ja richtig besserwisserisch  :Embarassed: 

Lieber Gruss

STiGGiLast edited by STiGMaTa_ch on Sat Jan 22, 2005 10:41 pm; edited 1 time in total

----------

## _hephaistos_

 *STiGMaTa_ch wrote:*   

> Dort wird dir gezeigt, wie du Ebuilds, welche du NIE benötigst maskieren kannst, so dass bei einem "emerge --sync" diese ebuilds einfach übersprungen werden...

 

das problem dabei ist, dass wenn man "neue" pakete installen will, dann fehlen diese...

ev. so, dass portage "standardmäßig" online alle ebuilds herunterlädt (die braucht man ja zum mergen)

zum suchen jedoch würde eine file mit allen paketnamen und ev. einer kleinen beschreibung reichen...

dh: man hat 1 file mit ALLEN paketnamen und einer kl. beschreibung

will man was emergen, wir das ebuild runtergeladen und "gespeichert". dh: man hat nur ebuilds von installierten paketen auf der platte, kann aber jederzeit "offline" suchen...

 *Quote:*   

> Ausserdem weiss ich nicht wass du für ein Problem mit der Arbeitsgeschwindigkeit hast. Ein emerge PAKETNAME legt bei mir SOFORT los.

 

na, bei mir nicht... dauert unterschiedl. "lang" (ich weiß, das ist relativ)

ciao

----------

## hoschi

hephaistos6 hats ja schon geantwortet  :Very Happy: 

danke euch beiden

von esearch habe ich auch gehört, den besonders das suchen dauert viel zu lange, damit hätte man ja dann auch den index. aber das beseitigt das problem an sich ja nicht, und viele symptome. 

z.b. das ewige berechnen der abhängigkeiten, und das man den "gewaltigen" portage-tree wie einen klotz am bein mit sich rumschleppen muss

bei einer neuinstallation von gentoo frisst portage die hälfte vom gesamten platz weg, das kanns ja nicht sein - esearch lindert damit sozusagen nur das kopfweh durch seinen eigenen index (?)

und wie schon gesagt, pakete auf eigenen gefahr "wegsparen" erinnert mich zusehr an unsere staatsfinanzen   :Laughing: 

frage am rande:

es gibt ja die emerge option das zuerst alle daten runtergeladen werden, und dann das kompilieren startet - warum gibt es davon nicht die logische fortsetzung -> runterladen während dem kompilieren?

z.b. brauch ja das kompilieren von xorg recht lange, da wäre es doch nur schlau gleich mal gnome runterzuladen - multitasking quasi

vermisse diese möglichkeit schmerzlich - warum dürfen netzwerkkarte und  system nicht gleichzeitig arbeiten?

es hat ja nicht jeder eine onboard-netzwerkkarte von "billig-aus-taiwan" die praktisch alles von der cpu-machen lässt, und selbst wenn, so tragisch ist das ja nun wirklich nicht   :Rolling Eyes: 

----------

## hiroki

also ich bin sehr zufrieden mit der geschwindigkeit von portage, vor allemdie geschwindigkitszunahme durch das "neue" portage (2.0.50 oder 51,weiß es schon nicht mehr) war/ist immens und hat mich schwer beeindruckt, also jetzt vorallem beim abhängigkeiten berechnen [-pv].

das einzige, was mir jetzt noch geschwindigkeitsmäßig auffällt ist, dass nachdem der PC frisch gestartet wurde der erste aufruf von portage seeeehr langsam ist. und das liegt noch nicht mal am abhängigkeiten berechnen oder so, sondern es scheint mir wirklich nur am "hochfahren" von portage [python, laden der ganzen skripte in den speicher, kompilieren dieser skripte, und dann auch noch ausführung] zu liegen, da er lange zeit nichts ausgibt, und dann erst die ausgabe "calculation dependencies..." kommt.

jedenfalls finde ich es schon irgendwo notwendig, dass die ebuilds lokal vorliegen, denn müsste man sie immer [ausschließlich] online abrufen, hätten schonmal die leute ohne [funktionierendes] internet probleme. z.b. wenn die netzwerkkarte nicht mehr funktioniert, oder so. ihnen wäre dann jede chance vergönnt, ein bestimmtes paket neu zu installieren/emergen, da das ebuild einfach nicht da ist. evtl müssten sie noch zusätzliche tools installieren, die noch nicht auf dem system sind.

ich denke, dass debian [ich weiß nicht wie es genau ist] weniger als gentoo zu tun hat, keine ebuilds braucht, weil in den ebuilds schlicht weg die ganzen prozesse stehen, die zum runterladen, entpacken, kompilieren und installieren [und abhängigkeiten, etc.] angegeben sind. bei debian hingegen sind die abhängigkeiten [wei gesagt, ich vermute es] in den deb-paketen eingetragen, dann muss das system nur noch die verfügbaren versionen kennen und kalkuliert die abhängigkeiten aufgrund der informationen im deb-paket. zumindest steht bei rpmdie information im paket welche voraussetzungen das paket benötigt.

----------

## hiroki

ich hatte [glaube im portage-forum] einen vorschlag unter eine bestehenden vorschlag gesetzt, wie man das syncen verbessern könnte. es ist eine idee, ob es sich aber lohnt, machbar ist kann ich nicht einschätzen.

es wäre als alternative zum kompletten sync zu sehen:

es wäre meiner meinung nach vllt ganz gut etwas zu haben wie "emerge --sync gentoo-dev-sources", damit manwirklichnurein paket [und evtl. seine abhängigkeiten] aktualisieren kann, ohne dass dabei der komplette rest ge-sync-t wird. ziel ist vor allem die verkürzung des [langen] sync-prozesses wie auch die schonung der server-ressources, denn so synct man nur noch das was man braucht. das ist vor allem dann nützlich, wenn man am tag schon einmal gesynct hat, aber dann am abend z.b. merkt, dass eine neue version eines pakets vorliegt, das man gerne hätte. dann muss nicht noch der ganze rest der am tag aktualisierten ebuilds runtergeladen werden, und generell müsste nicht der gesamte portage-tree durchlaufen/durchsucht werden, nach zu aktualisierenden/löschenden ebuilds. aber auch wenn der letzte sync schon wochen her ist und man nur mal schnell ein programm installieren will [und davon die aktuallste version] könnte man dann sowas wie "emerge --sync mozilla -av" eingeben. das wäre so meine idee. darauf gekommen bin ich, weil ich selbst schon des öfteren

a) gerade ge-sync-t hatte und dann schon 5 minuten später auf packages.gentoo.org eine neue version von einem programm da war, das ich installieren wollte

b) ich es nervig fand, den kompletten portage-tree zu syncen [mitsamt des immensen zeit-verbrauchs], um ein einzelnes paket zu emergen.

sagt einfach mal was ihr davon haltet.

gruß.

----------

## Mindphaser

@hoschi: 500MB ?! Ganz so schlimm ist es nun auch wieder nicht....170MB bei mir, eventuell solltest du mal /usr/portage/distfiles aufräumen  :Wink: 

Ein Online-Portage fänd ich auch nicht so toll, hiroki nannte bereits genug contras, als Kompromiss könnte man einen solchen ja optional machen  :Smile: 

Die Suche und das "Updating Portage cache" liesse sich sicher noch ordentlich optimieren, AFAIK arbeiten die Jungs da auch drann. Bis das realisiert wird, kann man ja ein alternatives Datenbank Backend benutzen (darüber gibts hier im Forum einige Threads). Ich selber benutze MySQL dafür, was das "Updating Portage Cache" um immerhin 1 Minute beschleunigt, und das Dateisystem weniger belastet  :Smile:   Wer kein MySQL hat, oder es sich nur dafür nicht zulegen will (ich nutze MySQL auch für meinen Lokalen DSL Webserver  :Smile:  ), für den gibt es da noch eine andere Alternative, wie die heisst weiss ich jetzt nicht ausm Kopf, die suche hier sollte das aber schnell beantworten können  :Smile: 

----------

## Sandal Tolk

Also ich finde das Syncen nicht so tragisch. Ich mein das kann man ja mal anschmeißen, surft n bissl und nach 5 Minuten ist das fertig. Das darauf folgende Updaten mach ich meißt eh über Nacht, oder wenn ich weiß, dass ich noch ne Weile arbeiten muss, da das ja eh immer n weilchen dauert, da kommts auf den sync nicht an.

Allerdings ist der Speicherverbraucht von 500mb (sinds bei mir auch) schon recht hoch, da könnte man schon optimieren. Kann man das ganze nicht vielleicht in ein Archiv packen? Unkomprimiert kommt man immernoch schnell an ein bestimmtes ebuild ran? Ich mein, dass 100.000 kleine Dateien viel Platz wegnehmen lässt sich wegen der minimalen Clustergröße nicht übergehen...

Alternative wäre vielleicht noch ne Datenbank, ich meine die DB von ner Webseite, die ich Administriere schluckt 60 MB. Dazu gehören gute 100.000 Beiträge im Forum und einiges an Content auf der Webseite und ich meine Ebuilds sind doch nun wirklich ziemlich klein und man könnte sie von der Form her auch super in ne DB stecken. Abfragen der Datenbank geht dann auch fast genau so fix, wie aus dem normalen Dateisystem?

----------

## _hephaistos_

 *Mindphaser wrote:*   

> @hoschi: 500MB ?! Ganz so schlimm ist es nun auch wieder nicht....170MB bei mir, eventuell solltest du mal /usr/portage/distfiles aufräumen 

 

ich glaub du meinst mich hmm?

ich hab aber wirklich (gerade getestet) 444MB.

was mir aufgefallen ist in letzter zeit: es gibt von vielen paketen nur noch 1 version in portage!

zB skype oder so!

ciao

----------

## primat

Hallo,

wenn man sich wirklich ein online Modell überlegt, dann müsste es zum suchen doch reichen den esearch Index auf seinem Rechner zu haben, der ist etwa 1,3 MB groß. Man könnte diesen dann einfach irgendwo zentral auf einem Server bereitstellen, so dass man einfach nur diesen aktualisiert.

Gruss

----------

## Sas

Ich weiß zwar nicht wie apt-cache funktioniert, aber das geht definitiv auch wenn man offline ist. Genauso wie das 'emerge -p'-Äquivalent 'apt-get install -s'.

Womit wir auch gleich schon beim Problem wären: Wie sollen denn so Dinge wie Abhängigkeiten, die ja auf jedem System anders ausfallen (und natürlich auch die Use-Flags selbst) oder Portage-Overlays korrekt von emerge beim pretend berücksichtigt werden, wenn die entsprechenden ebuilds nicht komplett vorliegen? Die einzige Möglichkeit wäre wohl, sie an dieser Stelle schon on demand nachzuladen, aber ich habe auch nicht immer Inet-Verbindung, wenn ich mit dem Laptop mal ein Blick auf irgendwelche Abhängigkeiten werfen möchte.

----------

## sirro

Was die Geschwindigkeit angeht: [1] wirkt auf langsamen Rechnern Wunder. Mein emerge -pvuDt --newuse world ist damit auf einer lahmen kiste von ueber 15min(!!!) auf unter 2min gekommen. Einmal mit emerge metadata die mysql-db fuellen, sind bei mir 6MB mehr auf der Platte, und ab gehts...

[1] https://forums.gentoo.org/viewtopic.php?t=202050

----------

## schmutzfinger

Naja ich finde diesen Punkt eigentlich nicht so schlimm. Das gentoo paketmanagement zeitaufwändig ist würde ich einfach mal auf die extreme komplexität zurückführen. Ausserdem fällt das bisschen syncen und suchen einfach nicht ins gewicht, wenn man sowiese davon ausgehen muss, das ne installation wesentlich länger dauert als bei ner distri mit bin paketen. Die useflags machen es nunmal schwer, die und /etc/portage/ könnten bei jeder suchanfrage anders aussehen. Bei anderen distris hingegen, hat jeder die gleichen abhängigkeiten.

Wenn man nur mal fix informationen über ein paket braucht, dann geht die suche über http://gentoo-portage.com tatsächlich schneller, besonders wenn man gerade im hintergrund was installiert. Wenn man angemeldet ist kann man da auch seine useflags eintragen, ich weiss allerdings nicht ob man dann zusätzlich persönliche abhängigkeiten sieht. Selbst wenn, dürfte das wohl nur in den seltensten fällen stimmen.

Gleichzeitig runterladen und mergen, sollte allerdings wirklich möglich sein. Ich habe fast ethernet direkt ins netz, und ziehe meine sourcen mit ca 4-5MB/s. Da fällt das nicht so auf, aber mit dsl und grossen sourcen, kann man bestimmt ne menge zeit sparen.

----------

## Sas

Sehr cool, das DB-Backend für Portage kannte ich noch gar nicht!

----------

## hoschi

 *primat wrote:*   

> Hallo,
> 
> wenn man sich wirklich ein online Modell überlegt, dann müsste es zum suchen doch reichen den esearch Index auf seinem Rechner zu haben, der ist etwa 1,3 MB groß. Man könnte diesen dann einfach irgendwo zentral auf einem Server bereitstellen, so dass man einfach nur diesen aktualisiert.
> 
> Gruss

 

Wir haben ja schon längst ein Online-Modell, und zwar ein ziemliches unwirtschaftliches - 1.3 MB vs. 100.000 kleine Dateien - DAS IST DOCH KRANK!

Ich packe /usr/portage/distfiles am besten auf eine extra Reiser4-Partition, xfs ist halb doch ein Dateisystem für normale bis große Dateien.

@hiroki: Deine Argumentation "mit Internet-Pflicht" verstehe ich nicht, du wirst immer irgendwo eine Internetverbindung haben müssen, oder eine CD - das ist bei Windows/Linux/MacOS so

Außerdem ist es irgendwo peinlich da eine Distro ohne GUI schon von Haus aus mind. 700MB Speicherplatz braucht (mit Sources usw. mehr als 1GB nach der Installation).

Wenn ich schon daran denke wie winzig der Index wäre, wenn man den nur noch vom Sync-Server ziehen müsste - man denke nur an die Zeit und Stromersparnis! Wie gesagt, ich bin kein Anhänger des Thin-Client-Konzept, aber ob Index oder Ebuilds - wo ist da der Unterschied?

Also ich wäre geradzu begeistert  :Smile: 

----------

## hoschi

 *Sas wrote:*   

> Ich weiß zwar nicht wie apt-cache funktioniert, aber das geht definitiv auch wenn man offline ist. Genauso wie das 'emerge -p'-Äquivalent 'apt-get install -s'.
> 
> Womit wir auch gleich schon beim Problem wären: Wie sollen denn so Dinge wie Abhängigkeiten, die ja auf jedem System anders ausfallen (und natürlich auch die Use-Flags selbst) oder Portage-Overlays korrekt von emerge beim pretend berücksichtigt werden, wenn die entsprechenden ebuilds nicht komplett vorliegen? Die einzige Möglichkeit wäre wohl, sie an dieser Stelle schon on demand nachzuladen, aber ich habe auch nicht immer Inet-Verbindung, wenn ich mit dem Laptop mal ein Blick auf irgendwelche Abhängigkeiten werfen möchte.

 

Die Abhänigkeiten soll man ja ruhig Speichern, wenn man da so ansetzt wie z.B. 

-System

-Framebuffer

-XORG

-GTK2

-QT

Das sind ja nur ein paar "Wörter" in diesem Index, und in den Ebuilds wird bis jetzt ja nicht gespeichert was schon installiert ist - ich glaube also man kann das durchaus getrennt sehen und es stellt somit kein Problem dar - vielleicht wird er Index dann halb 5 MB groß  :Wink: 

----------

## Sas

Da ergibt sich aber das Problem, dass die Abhängigkeiten sich je nach USE-Flags unterscheiden, dann müsste zusätzlich noch generell rein, welche USE-Flags das Paket überhaupt verwendet, Keywords müssen auch berücksichtigt werden, und bald sind wir wieder beim ganzen ebuild.

Da erscheint mir die PortageDB in SQL durchaus sinnvoller, warum nutzt Portage nicht standardmäßig eine eingebettete MySQL-DB?

----------

## sirro

 *Sas wrote:*   

> Da erscheint mir die PortageDB in SQL durchaus sinnvoller, warum nutzt Portage nicht standardmäßig eine eingebettete MySQL-DB?

 

Auch wenn ich sie auf einem Rechner selber nutze: Nein bitte nicht standardmaessig eine MySQL-DB. Lieber per use-flag oder sogar per extra Paket (ala app-portage/mysql-portage).

----------

## Sas

Ja, meinetwegen auch als Option, aber was spricht denn in deinen Augen dagegen?

Ich bin nachwievor der Überzeugung, dass sich mit einem System a la esearch nicht mehr tun lässt als Suchen und das machen wir ja alle schon damit.

Zum Berechnen von Abhängigkeiten etc. ist es a) zu unflexibel und b) zu unaktuell.

----------

## sirro

 *Sas wrote:*   

> Ja, meinetwegen auch als Option, aber was spricht denn in deinen Augen dagegen?

 

Dagen spricht in meinen Augen, dass es fuer schnelle Rechner keine spuerbare Verbesserung gibt, aber wieder eine Schnippe Overhead draukippt. Zum anderen ist eines der Hauptargumente fuer mich immer noch, dass ich sehr viel Freiheit bei der Einrichtung meines Systems hab und mysql als DEPEND von portage geht IMO in die ganz falsche Richtung.

----------

## hoschi

Sehe ich auch so. MySQL für nen Desktop standarmässig  :Mad: 

----------

## Sas

Ich rede ja auch von einer embedded DB und nicht gleich vom ganzen Server.

Voteile - außer der Geschwindigkeit - gibt es doch alle, die eine DB eben mit sich bringt: Datenunabhängigkeit, standardisierter Zugriff, je nach Dateisystem in diesem Fall auch Platzersparnis, Transaktionen, einfacher umzusetzender Lock-Mechanismus, man könnte - ein paar Erweiterungen vorausgesetzt - sogar ganz einfach verschiedenste statistische Auswertungen vornehmen. Das emerge-log könnte auch in die DB.

Vorallem für die Entwicklung neuer Portage-Tools wäre das eine gute Basis.

----------

## sirro

 *Sas wrote:*   

> Ich rede ja auch von einer embedded DB und nicht gleich vom ganzen Server.

 

embedded hat doch den nachteil, dass man nicht so ohne weiteres auf einen externen Server umsteigen kann, oder?

embedded hin oder her. mysql als Pflicht faende ich gar nicht gut, als Option aber super.

 *Sas wrote:*   

> Vorallem für die Entwicklung neuer Portage-Tools wäre das eine gute Basis.

 

Dafuer kommt ja die API... und portageq gibts ja auch schon. Fuer die Toolsentwikclung sehe ich da nicht sooo den grossen Vorteil.

----------

## Sas

Ich habe mit MySQL embedded noch nicht gearbeitet, allerdings würde es mich doch sehr wundern, wäre der Umstieg auf den richtigen Server mit viel mehr Anpassung als der Änderung des ConnectionStrings verbunden.

Ja natürlich müsste es keine Pflicht sein, aber mit ner DB als Option müssten eben gleich zwei Systeme gepflegt werden, ich hätte da als Entwickler keine Lust zu.

Ich sehe es schon als großen Vorteil, vorhandenes SQL-KnowHow und vorallem auch bereitgestellte SQL-Funktionalitäten nutzen zu können. Da ließen sich Funktionen wie sie z.B. qpkg bietet beinahe mit einem Fünfzeiler schreiben - ein entsprechendes Datenbanklayout voraus gesetzt.

Aber vielleicht empfinde ich das nur so, weil ich in Datenbanken relativ bewandert bin, mit dem Speichern und Verarbeiten von Datenbank-ähnlichen Informationen auf Dateisystem-Ebene allerdings keine Erfahrung habe.

----------

## DarKRaveR

Mal ein paar GEdanke dazu:

Nehmen wir mal an, man würde nicht alle ebuild herunterladen, stattdessen gäbe es einen kompakten paketindex, in dem paketname,mögliche versionen, abhängigkeiten und beschreibungen (auch durchaus komprimiert) enthalten sind. Ein solcher index sollte recht klein sein, man kann ihn schnell syncen.

Mit einem solchen index kann ich offlien suchen, abhängikeiten identifizieren und ermitteln, welche ebuilds in welcher version nun wirklich gebraucht werden.

auch nicht installierte pakete sind schnell auffindbar, zumal kann man den index für eine volltextsuche ja offline aufbauen.

Es würden nur die die ebuils heruntergeladen, die gebraucht werden, die platzersparnis wäre vermutlich immens und da beim updaten des index einmal der abhängigkeitsbaum etc. aufgebaut wird, muß das nicht mehr on the fly geschehen. Wenn ich einen ebuild brauche, muß ich ihn herunterladen, zugegeben, aber wenn ich das paket emergen will, muß ich die pkaetquellen auch erst noch runterladen, ein wirklicher nachteil wäre es nicht.

Gehen wir weiter, nehmen wir mal an, die ebuild werden lokal in einem mörderarchiv, oder mehreren archiven, je teilbaum xyz abgelegt, die komprimiert sind - weitere platzersparnis. Wenn das Archiv eine HEaderstruktur hat, die wie folgt aussieht:

ebuild dateiname, unkomprimierte checksumme, offset innerhalb des archivs, so könnte man direkt schauen, wenn man die informationen für paket XYZ synced, ob sich a) eine ebuild datei geändert hat (dank uncompresed checksum) und ob ein ebuild dateiname vorhanden ist (man kann ja beim einlesen des archivheaders ein has o.ä. aufbauen). Solte eine datei sich geändert haben, extrahiert man sie und synced sie in einer normalen sync deltaübertragung, noch nicht lokal vorhandene dateien kann man auch entsprechend handhaben.

Sollten dann änderungen am archiv nötig sein, sammelt man eine gewisse menge davon und committed diese in blöcken, je nach der größe des archivs, sollte das ganze dann schneller gehen, als jede änderung einzeln zu comitten. (Nehmen wir mal an, man würde je ein archiv für eine applikationsgruppe machen, dann sollten sogar einzelne comits verdammt schnell gehen.

Jetzt mag man sagen: Moment, aber Komprimieren/Dekomprimieren ist ja zeitaufwendig, aber da ebuilds reiner text sind, sollte die kompressionsrate recht groß sein, das komprimierte file einzulesen und zu entpacken sollte weitaus weniger IO last produzieren und da die dateien klein sind recht fluchs gehen. Zumal man das entpacken, synchen und das anschließende neupacken und ins archiv einfügen ja wegthreaden kann, sprich, am anfang wir die erste zu ändernde datei entpackt, während ds sync extrahiet man die nächste zu updatende datei, am ende des syncs wird dann entsprechenddie änderung ins archiv comitted, während der nächste sync läuft und auch schon wieder die nächste datei extrahiert.

Bei Bedarf könnte man auch gleich mehrere je schritt extrahieren und während man mehrere synced, die nächsten vorbereiten und abgeschlossene comitten.

Natürlich, das ist mir klar, ist eine solche Implementierung nicht ganz so trivial, könnte wohl nicht mehr alleine in python realisiert werden und es ist schwieriger alles konsistent zu halten, aber insgesamt sollte es erheblich platz sparen, trafic chonen und viele aktionen beschleunigen.

------------------------------------------------

Sollte ich irgendwo massive Denkfehler gemacht haben, ruhig drauf antworten/eingehen, vorm Frühstück ist das Gehirn noch nicht auf Höchstleistung.

------------------------------------------------

So, ich war mal so frei das mal zu testen, also, Portage Tree ohne Distfiles auf Platte (du -sb) belegt 97614786 bytes.

Reale Bytes aller files aufsummiert: 84031832

Das heißt wir reden von alleine rund 13 MB Verschnitt, wegen der vielen kleinen Dateien ...

Mit zlib komprimiert: 40337116

Das heißt, über 50% des Platzes könnte gespart werden, wenn der komplette Tree lokal gehalten wird. Zumal da noch nicht berücksichtig ist, daß wenn man die Files zusammengruppiert auch bei diversen Filesystemen weniger Platz für die Directories/Inodes benötigt wird (jene die das skalieren können). Geht man jetzt davon aus, daß ein übliches System vielleicht auch nur 50% der Pakete braucht (der ebuild files) könnte man den Tree auf rund 20 MB (oder weniger) schrumpfen.

Weiterer Vorteil wäre, wenn man zudem für die dependencies ein getrenntes file synchron hält bei Veränderungen, und einen suchindex kreiert, man deutlich mehr Version der einzelnen Pakete im Tree halten kann und trotzdem noch weniger Platz benötigen wird. Das wäre doch ein erheblicher Vorteil - Würde ich mal so meinen !?

Die einzige Veränderung auf Serverseite wäre halt, daß man ein zusätzliches File bereitstellen müsste, daß eben die Dependencies beinhaltet, sowie einen Suchindex.

Ich finde das wäre echt eine Überlegung wert .....

----------

## hoschi

Hallo, ich bin frustriert  :Sad: 

Wir sind bei über 120.000 Dateien bei einem "emerge sync", dieser Vorgang dauert inzwischen bei vielen über 20 Minuten - ohne das überhaupt ein einziges  Update eingespielt wird, liebe Entwickler, ihr müsst jetzt bitte was tun, ich glaube Portage ist in der Zeit stehen geblieben, das bisherige Prinzip ist aus meiner Sicht, so nicht mehr wirklich tragbar.

Bitte ließt was ich hier vorschlage, und habt keine Angst - keiner, auch ich nicht, werden euch eure Ebuilds weg nehmen, da gibts nur eine kleine Änderung (siehe ganz unten).

 *Quote:*   

> <edit> hab den Thread mal nach oben befördert, und bin hoffentlich nicht zu Kampflustig geworden, aber inzwischen denken da scheinbar einige Leute wie ich.
> 
> Schaffen einer Index-Datei die folgende Daten enthält:
> 
> Paketname
> ...

 

Noch ein wichtiger Hinweis:

Ebuilds werde nicht, ich wiederhole mich, nicht abgeschafft. Sie werden ledglich dann geladen, wenn sie gebraucht, oder gewünscht werden - also beim mergen eines Paketes. Ich denke da sogar über eine Parameter wie "--ebuild" für Portage nach, der nur das Ebuild runterlädt. 

Ich bin der Ansicht, dass sich nur so viele Gegenüber meiner Idee mit der Index-Datei streuben, weil sie zugang zu Ebuilds haben wollen, und will euch deswegen in diesem Punkt beruhigen.

----------

## rokaef

die idee ist eigentlich gut..und suchen kann man ja dann immer noch auf www.gentoo-portage.com.

----------

## l3u

Ich bin auch der Meinung, daß man was an dem System von Portage ändern sollte. Und das naheliegendste ist IMHO genau das, was hoschi geschrieben hat: Wozu für _alle_ Programme im Portage Tree _alle_ Kompilieranweisungen ziehen? 90% davon werde ich nie emergen. Und wenn man das ganze auf's wesentliche reduzieren würde, nämlich Name, Versionsnummer, Beschreibung und Abhängigkeiten, dann würde man gleich noch haufenweise Verzeichnisse unter /usr/portage einsparen. Weil dann braucht nicht jedes Programm nochmal ein eigenes Verzeichnis, wo ebuild & Co. drinliegen, sondern dann gibt's z.B. nur noch /usr/portage/app-shells/ und drunter liegen dann als _Datei_, nicht mehr als Verzeichnis "ash", "bash", etc.

Bzw. man legt den ganzen Kram in ner kleinen Datenbank ab (BerkeleyDB zum Beispiel?) und reduziert somit nochmal die tausenden Dateien und Verzeichnisse. In dem Moment, wo ich dann "emerge programm" eingebe, wird doch sowieso die Quelle des Programms gezogen. Was will ich also schon vorher mit dem ebuild? Es würde doch nichts schaden, wenn das erst dann runtergeladen werden würde.

Egal wie, irgendwei muß es doch gehen. IMO ist Apt grundsätzlich vergleichbar mit Portage. Aber apt-get update dauert nur einen Bruchteil so lang wie emerge sync. Also müßte man da doch was machen können?!

----------

## sirro

 *Libby wrote:*   

> 90% davon werde ich nie emergen.

 

Na dann...

Mal ehrlich: Wozu zieht ihr auch bei jedem sync den kompletten Tree? Auf meiner Workstation synce ich nur alle zwei wochen komplett (und selbst da filter ich bei den Excludes noch sachen wie games-*, rox-*, snustep-*, net-p2p, gnome-* und viel mehr, die ich nie brauchen werde. Alle 2-3 Werktage synce ich dann nur die Pakete, die ich installiert habe. Das ist nur ein Bruchteil der vorhanden Pakete (~ 200). Das spart viel unnoetigen Traffic...

Ich will nicht sagen, dass das jetzige System nicht verbesserungswuerdig ist (auf lange Sicht ist es das mit Sicherheit). Aber anscheinend gibt es Leute, die lieber rummosern und mit der Debian-Flucht winken als mal etwas dran zu tun.

 *sirro [1] wrote:*   

> 88% weniger pro Woche als vorher

 

[1] https://forums.gentoo.org/viewtopic-t-173433.html

----------

## chtephan

Ja, an eine BDB habe ich auch gedacht.

Das Problem ist, daß der komplette Portage-Tree abgeglichen wird und anschließend auf dem Client der Metadata-Cache neu generiert wird. Dadurch muß das System mehrfach durch abertausende kleiner Dateien durchwühlen.

Den ganzen Prozeß sollte man auf den Server verlagern. Und zudem einen dateibasierten Cache in eine Datenbank umwälzen, die geschickte Indizes unterstützt.

Der Abgleich erfolgt dann über ein neu zu entwerfendes Protokoll, der den lokalen Cache auf aktuellen Stand bringt. Für den einfachen Fall würde es genügen, ein Änderungsdatum zu schicken, und man bekommt alle Änderungen der Metadaten seither zurück.

Wenn man den kompletten Portage-Tree trotzdem weiter behalten will, kann man ja ein FEATURES-Flag setzen. Vor einem Abgleich würde er dann kurz den lokalen Portage-Tree nach Änderungen untersuchen (wieder mit Änderungszeit), und dann im lokalen Cache das vermerken (z.B. indem er eine Prüfsumme vom Gesamtverzeichnis des Ebuilds vorhält, die dann direkt verglichen wird).

Also zusammenfassend:

- Man erhält sich die Vorteile von rsync, indem man seine Hauptmechanismen (Änderungszeit, Prüfsumme) in ein neues, dediziertes Protokoll überträgt

- Man spart sich eine Regenerierung des Metadaten-Cache auf dem Client, in dem man statt des kompletten Portage-Trees nur noch die Metadaten mit dem Server direkt abgleicht

- Teile des Portage-Trees (Ebuild) brauchen nur noch bei Bedarf geladen zu werden (spart Platz und Traffic)

- Der Metadaten-Cache wird mittels einer (filebasierten) Datenbank, z.B. BDB und geschickten Indizes vorgehalten

- bei einem Crash der Datenbank ist ein kompletter Download oder eine Rekonstruktion der defekten Datensätze via Prüfsumme auch recht schnell bewerkstelligt (kann, wenn clever gemacht, ja sogar automatisch erkannt und korrigiert werden)

Ich denke, von einer solchen Änderung würde jeder profitieren. Natürlich ist die Implementation nicht gerade trivial, es würde deutlich mehr Programmierarbeit an Portage erfordern und Teile müßten komplett neu implementiert werden. Aber angesichts der exponentiellen Wachstumsgröße des Portage-Trees sollte man echt handeln.

Und jetzt sollte jemand den Text auf englisch übersetzen und in einem gescheiten Forum posten.  :Wink: 

----------

## sirro

 *chtephan wrote:*   

> - Man erhält sich die Vorteile von rsync, indem man seine Hauptmechanismen (Änderungszeit, Prüfsumme) in ein neues, dediziertes Protokoll überträgt

 

Ich bin mir nicht sicher, ob viele der Rsync-Mirror-Betreiber sowas akzeptieren wuerden. Rsync laeuft schon auf vielen Uni-Servern, da ist der Schritt Gentoo drauzulegen ein leichtes. Aber ein neues Protokoll ist schon ein viel groesserer Schritt. Wie gross ist ueberhaupt der Anteil der Uni-Mirrors momentan? Ich hab so das Gefuehl, dass es immer mehr private/Firmen-Mirrors werden.

IMO sollte ein neues Verfahren auf einem bestehenden und verbreiteten Protokoll aufbauen.

----------

## mathes.s

Hi,

ich habe einen Router auf dem Gentoo läuft den sync ich einmal wöchentlich, da ich auch nur isdn habe. Es dauert schon recht lange vorallem da es sich nur um einen P2 mit 400Mhz handelt. Denn rest der gentoo rechner bei mir im Netz sync ich einfach an den router damit spare ich auch schon zeit und die distfiles verteile ich per nfs im Netz. 

Ich hätte aber noch eine Idee wie man den Traffic auf den Distfileservern im Inet reduzieren könnte. Wäre es nicht möglich statt wget für den download bittorrent zubenutzen dann müssten in den ebuilds nur die tracker server eingetragen sein und die last von den servern würde sich auf das Netz verteilen und jeder der gerade ein distfile runter lädt lädt es auch direkt wieder ins netz. Ich weiß zwar nicht so ganz ob dies wirklich möglich ist, aber ich halte die Idee für interessant. 

mfg Mathes

----------

## basiaf

bittorrent ist zwar vom prinzip her ganz gut, aber :

1. nicht jeder kann oder möchte seinen upload für distfiles an andere zur verfügung stellen

2. erzeugt das nur wieder eine weitere (unnötige) abhängigkeit und damit ballast

3. ist bittorrent auf zusätzliche konfiguration von ports angewiesen um vernünftig zu laufen

4. erzeugt bittorrent auf langsamen rechnern zudem zu viel overhead an cpu & ram

von daher wäre das ebenfalls keine praktikable lösung finde ich...

----------

## HeadbangingMan

Den meisten Leuten wäre wohl schon geholfen, wenn es eine Möglichkeit gäbe, Portage auf einem Rechner statt auf allen zu halten.

Beispiel: Ich habe

- Router (24/7)

- Fileserver

- Workstation

- Notebook

alle mit Gentoo.

Da der Router eh durchläuft, kann er wegen mir die ganze Nacht syncen, rechnen oder was auch immer.

Zur Zeit habe ich den Router als gentoo-rsync-mirror für's LAN. Den Tipp mit dem mysql-backend werde ich mir mal anschauen, wenn ich viel Zeit habe. Aber schön wäre eben eine von den Entwicklern unterstüzte Möglichkeit Portage im LAN zentral zu halten (inklusive Distfiles).

Natürlich muss ein kleiner Teil auf den Clients bleiben, z.B. alle Informationen über bereits installierte Pakete u.s.w., aber das dürfte trotzdem wesentlich weniger sein, als es jetzt der Fall ist.

----------

## hoschi

 *sirro wrote:*   

>  *Libby wrote:*   90% davon werde ich nie emergen. 
> 
> Na dann...
> 
> Mal ehrlich: Wozu zieht ihr auch bei jedem sync den kompletten Tree? Auf meiner Workstation synce ich nur alle zwei wochen komplett (und selbst da filter ich bei den Excludes noch sachen wie games-*, rox-*, snustep-*, net-p2p, gnome-* und viel mehr, die ich nie brauchen werde. Alle 2-3 Werktage synce ich dann nur die Pakete, die ich installiert habe. Das ist nur ein Bruchteil der vorhanden Pakete (~ 200). Das spart viel unnoetigen Traffic...
> ...

 

Das ist leider nur ein Workaround, wie du ja selber sagst, und behebt das Problem nunmal nicht :/

Und vielleicht mossere ich herum, aber nur weil ich etwas bewirken will, ich kann nunmal praktisch gar kein C++, also versuche ich wenigstens meine Sicht der Lage zu schildern, und den Entwicklern eine hoffentlich gute und realisierbare Idee bereit zu legen - wenn ich das nicht täte und zu Debian wechseln würde, dann hätte ich Open-Source wohl falsch verstanden  :Wink: 

 *sirro wrote:*   

>  *chtephan wrote:*   - Man erhält sich die Vorteile von rsync, indem man seine Hauptmechanismen (Änderungszeit, Prüfsumme) in ein neues, dediziertes Protokoll überträgt 
> 
> Ich bin mir nicht sicher, ob viele der Rsync-Mirror-Betreiber sowas akzeptieren wuerden. Rsync laeuft schon auf vielen Uni-Servern, da ist der Schritt Gentoo drauzulegen ein leichtes. Aber ein neues Protokoll ist schon ein viel groesserer Schritt. Wie gross ist ueberhaupt der Anteil der Uni-Mirrors momentan? Ich hab so das Gefuehl, dass es immer mehr private/Firmen-Mirrors werden.
> 
> IMO sollte ein neues Verfahren auf einem bestehenden und verbreiteten Protokoll aufbauen.

 

Hmm,

ich erhoffe mir unter anderem eine Verringerung des Traffics, und ich glaube da würde sich jeder darüber freuen,

wünschenswert wäre natürlich ein schonender Wechsel, aber wenn etwas "nicht mehr gut ist", dann muss es der Evolution folgen.

Die Idee mit einer praktischen Verbreitung im Lan ist nett, aber das löst auch nicht das Kern-Problem

Ich habe weder einen zweiten Rechner, noch die Nerven mich damit auch noch zu Stressen (wobei es ja ums praktischer geht *g*) - und Noob freundlich ist es ja auch nicht gerade :/

----------

## chtephan

 *hoschi wrote:*   

> Und vielleicht mossere ich herum, aber nur weil ich etwas bewirken will, ich kann nunmal praktisch gar kein C++

 

Portage ist in Python geschrieben (bis auf div. kleine Helper).

----------

## gsven

Ich finde es Super das man den kompletten Tree bei sich hat, und habe kein Interesse daran es auf den Server auszulagern.

Die Idee mit der Datenbank find ich gar nicht schlecht, sicher gibts es da etwas schlankeres. Denn eine MySQL als dep von portage ist natürlich zu krass, 

ausserdem soll das System simpel bleiben damit.

Wie wäre es wenn man die ebuilds in einem Datenbank-basierten Dateisystem ablegt, welches dann als VFS gemountet werden kann.

1.) So hätte man die Möglichkeit zu entscheiden beim klassischen Weg zu bleiben und den Tree als Dateien vorliegen zu haben,

2.)  oder man benutzt die normalen Portage-tools, jedoch arbeitet als FS eine Datenbank im Hintergrund.

3.) Oder man benutzt die Datenbank und programmiert auch neue Portagetools die die Datenbank-Schnittstelle richtig benutzen, nicht über das FS Interface.

bei 1.) bleibt alles so wie es ist.

bei 2.) Man könnte Nutzen aus der DB ziehen, da das physikalische Dateisystem nicht so stark belastet wird, Arbeitsspeicher dafür natürlich umso mehr. Das ist immer die kehrseite einer Datenbank. Der Sync kann, wenn er mit dem DB Interface arbeitet, mit weniger traffic abgehandelt werden - Und suchen im Tree wären schneller, somit auch das berechnen des dep-graphen.

Zusätzlich hat man noch alle Möglichkeiten mit dem VFS Interface der Datenbank - man kann alle exisitierenden Tools benutzen, bei erhöhtem CPU und MEM Aufwand den das VFS mit der DB erzeugt.

bei 3.)  Wenn die Portage-tools komplett auf die DB abgebildet werden, also dafür programmiert wurden entstehen große Geschwindigkeitsvorteile, und es wird Festplattenplatz eingespart durch komprimierung. Durch die Mächtigkeit einer Datenbank sind viel komplexere System-Verwaltungstools möglich. Und, man hat die Chance die portage-programme mal nach und nach in einer Programmiersprache zu schreiben, ich halte nichts von python, aber naja.

----------

## hoschi

 *chtephan wrote:*   

>  *hoschi wrote:*   Und vielleicht mossere ich herum, aber nur weil ich etwas bewirken will, ich kann nunmal praktisch gar kein C++ 
> 
> Portage ist in Python geschrieben (bis auf div. kleine Helper).

 

Weiß ich, aber ohne C/C++ komme ich so oder so nicht weit  :Sad: 

Aber anders gefragt, warum ist Portage ausgerechnet in Pyton geschrieben, ich denke jetzt nicht gerade dass Portage von C profitieren kann, aber damit hätte man ja eine Abhängigkeit im Core-System weniger, interessiert mich nur  :Smile: 

<edit>

Kann niemand von uns mal die mal die Vorschläge (VFS-Datenbank, Index-Datei usw.) kurz übersetzen und in den englischsprachigen Teil des Forums pflanzen, wenn ich das mache versteht die hälfte der Community mein anliegen am Ende nicht  :Rolling Eyes: 

----------

## gsven

jo, würde meinen beitrag wohl auch in englisch verfassen, wenn einer Lust hat mit seinem Anzufangen soll er hier mal den link posten.

Ansonsten mach ich einen [edit] und schreib den nochmal in englisch drunter zum copy/pasten. Dann könnt ihr euchmal schlapplachen über meine englischkünste  :Smile: 

----------

## hoschi

ich probiere es gerade, werde es aber auf jeden fall vorher hier post - zu grausam *würg*

 *Quote:*   

> Hello Community,
> 
> i think we must change the background system of Portage!
> 
> The big point is that Portage is very slow, more than 120,000 files, more than 20 minutes for one "emerge sync" and nothing happend "really" on my box 
> ...

 

----------

## _hephaistos_

directory = verzeichnis  :Smile: 

----------

## hoschi

 *hephaistos6 wrote:*   

> directory = verzeichnis 

 

ahhhh - danke, muss der anhaltende drogenkonsum sein!

----------

## Earthwings

Will euern Eifer nicht dämpfen, aber wenn ihr die Suchfunktion nutzt, findet ihr bereits ein paar Threads dazu. Auf gmane.org ebenfalls (gmane.linux.gentoo.devel)

----------

## tobidope

Hi.

ich nutze Gentoo auch auf einer alten Mühle (P2 300 mit 156 MB RAM). Da mich das Metadaten generieren auch

wahnsinnig gemacht hat, ich aber kein mysql installieren wollte, habe ich ein relativ kleines DB-Modul erstell,

das auf cdb fußt. Wer's mal probieren möchte, hier der Link https://forums.gentoo.org/viewtopic-t-261580.html.

Das ist auch nur ein Herumdoktern an den Symptopmen, aber vielleicht hilfts dem einen oder anderen.

----------

## gsven

 *gsven wrote:*   

> Ich finde es Super das man den kompletten Tree bei sich hat, und habe kein Interesse daran es auf den Server auszulagern.
> 
> Die Idee mit der Datenbank find ich gar nicht schlecht, sicher gibts es da etwas schlankeres. Denn eine MySQL als dep von portage ist natürlich zu krass, 
> 
> ausserdem soll das System simpel bleiben damit.
> ...

 

my idea is a vfs-database system, much different to hoschi's indexed portage-Tree because,

I like the feature of having the whole portage tree on the system, so you only need the sourcecode tarball provided by the project und your done. I dont want to put

all those install Information to the server-side. I dont want gentoo linux systems to be depending on a server, isnt it a good thing that gentoo.org could be down tomorrow and you can continue working with your system just by writing some ebuilds? writing ebuilds is easy. People would share them.

But how can we handle the huge portage, sync'in it uses lot of resources. Searching and calculating deps takes longer and longer. And the portage tree allready takes some hundred megabytes from your harddisk.

My idea is to use a database, a tiny one if possible. I read about this portage in mysql thing. Having mysql as a dep on portage would be horrible, but there are solutions on that point and i like the idea of handling ebuilds in a DB. 

What if we would use the database in two ways, with two interfaces. One would be a virtual file system, you could mount it and have the portage tree litter like you used to know. All portage tools would still work, thats the good point. And you are able to unmount the vfs and use a file based portage tree again.

Benefits from this system would be the use of compression, the less use of physical access to your harddrive. And the speed a database can give you. Syncing your database with a server would perform better than syncing 100.000 very little files. You recieve the speed of a database not without costs, more memory consumption would be one disadvantage, also the cpu time needed to compress and handle the DB tables and internal indexes. Another one would be the additional layer to access the portage-tree. You cant have it all  :Smile:  .

One by one new portage-tools would be programmed, working with the native database interface - another great speed up and the possibility of much more complex functions would be the results. The database is not only fast, its powerful.

And, the change to a database based portage can be a migration, it doesnt need a day where it all breaks.

----------

## c07

Übrigens existiert fast die ganze nötige Infrastruktur schon, um nicht den ganzen Tree syncen zu müssen. In $PORTDIR/metadata/cache ist alles schön kompakt drin, was man braucht, um zu entscheiden, welches Ebuild installiert werden muss (einzige Ausnahme ist, dass damit die Gesamtgröße der Downloads noch nicht berechnet werden kann). Es ist mir ein Rätsel, warum das nicht genutzt wird.

Im einfachsten Fall könnte man $PORTDIR/metadata, $PORTDIR/profiles und $PORTDIR/eclass regulär syncen und bei Bedarf (wenn ein Paket tatsächlich installiert werden soll) zusätzlich das Verzeichnis, wo das Ebuild drin ist. Das ist etwas Verschwendung, wär aber mit nur minimalen Änderungen realisierbar.

Prinzipiell ist rsync für das Bereitstellen der Metadaten ziemlich gut geeignet. Es ist zwar geschwindigkeitsmäßig sicher nicht das Optimum, hält aber den nötigen Traffic klein (die einzelnen Metadaten-Dateien ändern sich fast nie) und bedeutet serverseitig einen geringen Aufwand. Wenn man will, kann man das dann immer noch lokal in ein günstigeres Format bringen.

Dass Portage bei der Suche langsam ist, liegt übrigens nicht nur an den vielen Dateien. Selbst die Holzhammermethode ist noch deutlich schneller als ein "emerge -S":

```
for file in $PORTDIR/metadata/cache/*/*; do sed '8!d;/suchbegriff/IQ;Q1' $file && echo $file; done
```

----------

## hoschi

 *gsven wrote:*   

>  *gsven wrote:*   Ich finde es Super das man den kompletten Tree bei sich hat, und habe kein Interesse daran es auf den Server auszulagern.
> 
> Die Idee mit der Datenbank find ich gar nicht schlecht, sicher gibts es da etwas schlankeres. Denn eine MySQL als dep von portage ist natürlich zu krass, 
> 
> ausserdem soll das System simpel bleiben damit.
> ...

 

danke  :Smile: 

ich poste das jetzt, sie werden mich schon nicht umbringen  :Rolling Eyes: 

----------

## hoschi

https://forums.gentoo.org/viewtopic-t-301304.html

kann man noch schöner machen, also ruhig verbesserungen posten!

----------

## Carlo

hoschi, solche threads wie Du ihn gestartet hast kommen immer mal wieder. Keine Idee ist neu, teilweise ist das Verständnis von Portage nicht da und letztendlich zählt nur, was in Code "gegossen" wird. Gerade die Aussage es sei peinlich, daß Gentoo so viel Speicherplatz benötigt, ist in Zeiten in denen man 20GB Festplatten allein aus Altersgründen wegwerfen sollte, völliger Unsinn. Wer kein zentrales Repository für seine Rechner anlegt, ist selber schuld. Gentoo ist nicht statisch und es ist illusorisch zu erwarten, daß die Mirror-Betreiber die Rechenleistung bezahlen, andauernd aktualisierte Indizes für alle mögliche Use Flag,Architektur,Ebuild-Kombinationen zu erstellen und vorzuhalten. Abgesehen davon müßte der Index sowieso neu erstellt werden, wenn ein (lokales) Overlay ins Spiel kommt.

----------

## hoschi

 *Carlo wrote:*   

> hoschi, solche threads wie Du ihn gestartet hast kommen immer mal wieder.
> 
> 

 

Alles andere hätte mich sehr überrascht.

 *Quote:*   

>  Keine Idee ist neu, teilweise ist das Verständnis von Portage nicht da und letztendlich zählt nur, was in Code "gegossen" wird.

 

Logisch, deswegen sollte man auch darüber diskutieren - und dann sollte man, hoffentlich, von offizieller Seite aus etwas unternehmen.

 *Quote:*   

> Gerade die Aussage es sei peinlich, daß Gentoo so viel Speicherplatz benötigt, ist in Zeiten in denen man 20GB Festplatten allein aus Altersgründen wegwerfen sollte, völliger Unsinn.

 

Das die hälfte der nackten Installation für Portage drauf gehen, erscheint dir also normal? Ein nacktes Gentoo genau so groß ist wie Windows-XP?

 *Quote:*   

> Wer kein zentrales Repository für seine Rechner anlegt, ist selber schuld.

 

Hä? Gehts noch?

 *Quote:*   

> Gentoo ist nicht statisch und es ist illusorisch zu erwarten, daß die Mirror-Betreiber die Rechenleistung bezahlen, andauernd aktualisierte Indizes für alle mögliche Use Flag,Architektur,Ebuild-Kombinationen zu erstellen und vorzuhalten. 

 

Verstehe ich nicht, was soll den der Server schon machen?!

Nehmen wir mal meine Modell, demnach stellen die Mirror-Server in Zukunft die Ebuilds, die Sync-Server werden wohl eher entlastet, nur noch ein bis maximal zwanzig Dateien vorzuhalten, diese eventuell auch noch komprimiert - da könnten sogar noch die Proxy-Server von T-Online und Co. an Bedeutung gewinnen.

 *Quote:*   

> Abgesehen davon müßte der Index sowieso neu erstellt werden, wenn ein (lokales) Overlay ins Spiel kommt.

 

Genauer? Wieso neu erstellen? Der Index kommt von Rsync-Server, an dem fummelt der Client nur rum, wenn es man einen Sync durchführt?

Knackpunkt scheint wohl deine Merkwürdige "Kombiniation" zu sein, ich weiß zwar nicht wie du auf so was kommt, aber vergiss es - einmal alle halbe Stunde gibts auf Rsync-Server-Seite nachschub, und daran wird wohl auch niemand was ändern wollen.

----------

## Carlo

 *hoschi wrote:*   

>  *Quote:*    Keine Idee ist neu, teilweise ist das Verständnis von Portage nicht da und letztendlich zählt nur, was in Code "gegossen" wird. 
> 
> Logisch, deswegen sollte man auch darüber diskutieren - und dann sollte man, hoffentlich, von offizieller Seite aus etwas unternehmen.

 

Portage wird nicht in solchen Threads weiterentwickelt und die Unzulänglichkeiten und Bugs sind nur zu gut bekannt. Nur werden sie nicht "mal eben so" in zwei drei Minor-Releases ausgeräumt.

 *Quote:*   

> Das die hälfte der nackten Installation für Portage drauf gehen, erscheint dir also normal? Ein nacktes Gentoo genau so groß ist wie Windows-XP?

 

Der Vergleich würde standhalten, wenn Gentoo eine Binärdistribution vom Umfang von Windows wäre. So wie es ist, ist es nicht nur normal, sonderen imho ausgesprochen positiv.

 *hoschi wrote:*   

> Hä? Gehts noch?

 

Die Frage nach der Kinderstube erspare ich mir.

 *hoschi wrote:*   

> Verstehe ich nicht, was soll den der Server schon machen?!

 

Die wesentliche zeitraubende Phase ist das Cache-Update. Und das hängt von den lokal gewählten Use-Flags ab, ist mithin nicht für alle Clients gleich. rsync ist ziemlich effizient, die Anzahl der übertragenen Dateien ist eher uninteressant. Die paar Bytes mehr oder weniger spielten allenfalls bei Modem-Verbindung eine Rolle.

 *hoschi wrote:*   

> Genauer? Wieso neu erstellen? Der Index kommt von Rsync-Server, an dem fummelt der Client nur rum, wenn es man einen Sync durchführt?

 

Ich hätte Cache schreiben sollen, nicht Index.

----------

## gsven

Hi Carlo, ich für meinen Teil war nicht davon ausgegangen das wir hier die Welt von Gentoo verändern  :Wink: 

Aber alleine die Tatsache über sowas zu diskutieren (ist ja ein Forum hier), sorgt dafür das sich die Teilnehmer

mit dem System mehr beschäftigen.

----------

## c07

 *Carlo wrote:*   

> Gentoo ist nicht statisch und es ist illusorisch zu erwarten, daß die Mirror-Betreiber die Rechenleistung bezahlen, andauernd aktualisierte Indizes für alle mögliche Use Flag,Architektur,Ebuild-Kombinationen zu erstellen und vorzuhalten.

 

Es geht doch nicht drum, fertig berechnete Abhängigkeiten bereitzustellen, sondern nur darum, die nötigen Daten in einem günstigen Format ohne die ganzen Ebuilds zu haben. Und das gibt es eben schon in Form von metadata. Allenfalls eine Trennung nach Architekturen wär u.U. sinnvoll, aber das ist zweitrangig.

 *Carlo wrote:*   

> Abgesehen davon müßte der Index sowieso neu erstellt werden, wenn ein (lokales) Overlay ins Spiel kommt.

 

Overlays werden in /var/cache/edb sowieso völlig getrennt gehalten.

 *Carlo wrote:*   

> Die wesentliche zeitraubende Phase ist das Cache-Update. Und das hängt von den lokal gewählten Use-Flags ab, ist mithin nicht für alle Clients gleich.

 

Das ist auch eine Sache, die ich nicht ganz kapier. Im Prinzip wird da doch einfach $PORTDIR/metadata/cache nach /var/chache/edb/dep/$PORTDIR kopiert. Bei Overlays ohne vorhandene Metadaten werden sie extrahiert. Und dann gibts da noch die *.cpickle-Dateien, deren Sinn ich nicht kenn, bei denen aber der Aufwand der Erstellung wohl eher nicht in einem vernünftigen Verhältnis zum Nutzen steht. Die Abhängigkeiten lassen sich ziemlich flott direkt aus den Metadaten berechnen, und die USE-Flags sind ja auch lokal nicht statisch. Ich kann sie jederzeit ändern oder sogar im Environment andere angeben.

Zur Größe von $PORTDIR: Mir gehts zwar eher um den Traffic als um den lokalen Platzbedarf, aber hier werden effektiv Sourcen von Sachen vorgehalten, die mit dem System gar nichts zu tun haben. Die Ebuilds haben keinen qualitativen Unterschied zu den restlichen Sourcen in $DISTDIR. Wenn man sie als Bestandteil des Systems betrachtet, müsste man auch das $DISTDIR mitsyncen.

Und 20GB-Platten sind noch nicht unbedingt schrottreif. 40GB-Platten werden noch hergestellt, und für alle, die kein extremes Datenaufkommen durch Filesharing o.Ä. haben, ist alles Andere Luxus.

----------

## Carlo

 *gsven wrote:*   

> Hi Carlo, ich für meinen Teil war nicht davon ausgegangen das wir hier die Welt von Gentoo verändern 
> 
> Aber alleine die Tatsache über sowas zu diskutieren (ist ja ein Forum hier), sorgt dafür das sich die Teilnehmer
> 
> mit dem System mehr beschäftigen.

 

Hierbei geht es um implementationsspezifische Dinge. Da hilft nur sich den Quellcode anzugucken und Patches zu schreiben.

 *c07 wrote:*   

> Es geht doch nicht drum, fertig berechnete Abhängigkeiten bereitzustellen, sondern nur darum, die nötigen Daten in einem günstigen Format ohne die ganzen Ebuilds zu haben. Und das gibt es eben schon in Form von metadata. Allenfalls eine Trennung nach Architekturen wär u.U. sinnvoll, aber das ist zweitrangig.

 

Das bringt nur keinesfalls den erhofften Geschwindigkeitsrausch und müßte aus allerlei Gründen gut bedacht sein.

 *c07 wrote:*   

>  *Carlo wrote:*   Abgesehen davon müßte der Index sowieso neu erstellt werden, wenn ein (lokales) Overlay ins Spiel kommt. 
> 
> Overlays werden in /var/cache/edb sowieso völlig getrennt gehalten.

 

Die Berechnung bezieht aber alle Overlays mit ein. Nicht umsonst bekomme ich bei gewissen Updates DEPEND/*DEPEND Fehler um die Ohren geschmissen und muß dann mein Overlay richten.

 *c07 wrote:*   

> Das ist auch eine Sache, die ich nicht ganz kapier. Im Prinzip wird da doch einfach $PORTDIR/metadata/cache nach /var/chache/edb/dep/$PORTDIR kopiert. Bei Overlays ohne vorhandene Metadaten werden sie extrahiert. Und dann gibts da noch die *.cpickle-Dateien, deren Sinn ich nicht kenn, bei denen aber der Aufwand der Erstellung wohl eher nicht in einem vernünftigen Verhältnis zum Nutzen steht. Die Abhängigkeiten lassen sich ziemlich flott direkt aus den Metadaten berechnen, und die USE-Flags sind ja auch lokal nicht statisch. Ich kann sie jederzeit ändern oder sogar im Environment andere angeben.

 

Tja, darauf achtet Portage und nutzt in dem Fall nicht die gecachten Daten. Die Entwicklerschaar ist heiß auf's Caching. Warum ist mir persönlich ein Rätsel, lediglich den Sinn einer Konsistenzprüfung sehe ich. 

 *c07 wrote:*   

> Zur Größe von $PORTDIR: Mir gehts zwar eher um den Traffic als um den lokalen Platzbedarf, aber hier werden effektiv Sourcen von Sachen vorgehalten, die mit dem System gar nichts zu tun haben. Die Ebuilds haben keinen qualitativen Unterschied zu den restlichen Sourcen in $DISTDIR. Wenn man sie als Bestandteil des Systems betrachtet, müsste man auch das $DISTDIR mitsyncen.

 

Außer das sie die Metadaten enthalten. Allein von den mir bekannten Bugs her und der Tatsache, daß Gentoo ein gewisses Maß an Abwärtskompatibilität wahren muß, denke ich nicht das Portage sich in der Hinsicht so schnell ändern wird. Letztendlich muß man nicht den kompletten Baum synchronisieren  :Arrow:  /etc/portage/rsync_excludes, man portage.

 *c07 wrote:*   

> Und 20GB-Platten sind noch nicht unbedingt schrottreif. 40GB-Platten werden noch hergestellt, und für alle, die kein extremes Datenaufkommen durch Filesharing o.Ä. haben, ist alles Andere Luxus.

 

Es war zugegebenermaßen pointiert formuliert, und für Notebooks evtl. nicht korrekt. Wer sich auf eine Soure-Distribution einläßt sollte allerdings wissen, daß ein bißchen Platz nötig ist. Wir reden hier über derzeit ca. 550MB für knapp 9000 Pakete und die Profile. Das ist doch lächerlich.

----------

## c07

 *Carlo wrote:*   

> Das bringt nur keinesfalls den erhofften Geschwindigkeitsrausch und müßte aus allerlei Gründen gut bedacht sein.

 

Natürlich bringt das keine Performance, außer dass das Syncen etwas schneller wird und das Dateisystem entlastet wird. Bedenken muss man da nicht viel. Es geht ja nicht um eine neue Technik, sondern nur um das Abwerfen von Ballast, der größtenteils eh nicht verwendet wird, solang man die Sachen nicht installiert.

 *Carlo wrote:*   

> Außer das sie die Metadaten enthalten. Allein von den mir bekannten Bugs her und der Tatsache, daß Gentoo ein gewisses Maß an Abwärtskompatibilität wahren muß, denke ich nicht das Portage sich in der Hinsicht so schnell ändern wird.

 

Die Metadaten in den regulären Ebuilds werden aber gar nicht verwendet, es zählt nur ihre bloße Anwesenheit (hab ich grad verifiziert: Portage hat offenbar gar kein Problem mit leeren Dummy-Ebuilds, solang nur die mtime stimmt).

Abwärtskompatibilität wär ja gegeben. Wer Portage-fremde Tools verwendet, die die Anwesenheit aller Ebuilds voraussetzen, müsste halt weiter auch die Ebuilds syncen. Es ging nur drum, inexistente Ebuilds bis zur tatsächlichen Installation zuzulassen und dann zusammen mit den restlichen benötigten Dateien zu holen. Wenn man auf die Angabe der Downloadgröße nicht verzichten will, müsste dafür noch ein Feld in den Metadaten angehängt werden.

 *Carlo wrote:*   

> Wer sich auf eine Soure-Distribution einläßt sollte allerdings wissen, daß ein bißchen Platz nötig ist.

 

Die Paketverwaltung muss sich da nicht grundsätzlich unterscheiden. In einem RPM-System sind die mit den Ebuilds vergleichbaren Informationen schließlich auch Teil vom Download und nicht der Paketverwaltung. Und ob ChangeLogs gesynct werden (die fressen wohl den größten Teil vom Traffic) hängt von der Sourcebasiertheit erst recht nicht ab.

Überhaupt könnte eine Source-Distribution bezüglich dem Downloadvolumen wesentlich sparsamer als eine Binärdistribution sein, wenn vernünftige Diffs verwendet würden. Auch da ist nur Gentoo so extrem verschwenderisch. Aber das ist ein anderes Thema.

----------

## hoschi

Verschwenderisch, dieses Wort trifft doch den Nagel auf den Kopf!

Wie werfen Rechenzeit, Arbeitsspeicher, Bandbreite und Festplattenkapazität um uns, die wir viel sinnvoller gebrauchen könnten z.B. fürs das Kompilieren!

Und da muss sich was ändern (ich drück das mal so harsch aus), und ich hoffe doch stark dass sich die Entwickler schon längst damit auseinander setzen, und nicht erst durch solche Threads aufgefordert werden, sondern weiter angeregt und angefeuert  :Very Happy: 

Abwärtskompatibilität ist zwar nett, aber nicht immer möglich, und wir haben ja schon ein Gedanken-Modell welches genau diese erfüllen würde.

Würde mich interessieren was bei den Devs so abgeht, vielleicht schreib ich mal ne Mail ans Portage-Team, kann nie verkehrt sein.

----------

## Genone

Anmerkung vorweg: Ich hab nur die erste Seite gelesen, falls ich auf Seite 2 und 3 irgendwas wichtiges verpasst habe bitte sagen.

Also mal was "offizielles", auch wenns komplett inoffiziell ist:

1.) Platzverschwendung: Vorneweg: wenn man hier mit Zahlen um sich schmeisst, bitte die Messmethode mit angeben. Der Portage Tree hat keine 500 MB, die Zahl kommt wahrscheinlich von du und sagt damit nur, wieviel Platz das Dateisystem für den Tree reserviert hat. Die reine Datenmenge im Tree ist wesentlich geringer (vermutlich unter 100 MB).

2.) Eine einfache und vermutlich hocheffiziente Verbesserung (in Bezug auf den Platzbedarf) dürfte die Nutzung von komprimierten Dateisystemen sein. Problem: es gibt soweit ich weiss keine komprimierten Dateisysteme mit Schreibzugriff.

3.) Der allgemeine Vorschlag des "on-demand Ebuild Fetchings" wird in naher Zukunft nicht umgesetzt, da es da ca. ne Trillion Probleme mit gibt, u.a. weil dann Syncs nicht mehr als atomar angesehen werden können, von Problemen mit Eclasses und ähnlichem mal gar nicht zu reden. Oder anders gesagt: Der Tree ist nicht dafür ausgelegt.

4.) Die Sync Zeit ist nur zum Teil vom Tree abhängig, der ganze Teil der während "Cache Update" passiert ist unabhängig davon wie der Tree upgedatet wird.

5.) Was wahrscheinlich gemacht werden kann/wird ist, dass wir auf die Mirrors zusätzlich zu den Snapshot Tarballs auch Snapshot-Dateisystemimages (als zisofs oder squashfs) vorhalten, was den Speicherbedarf enorm reduzieren sollte, da nur noch eine Datei gespeichert wird. Wer Zeit und Lust hat kann ja mal damit rumexperimentieren und den Speicherbedarf sowie Performance vergleichen und hier posten was es bringt oder kostet.

6.) partielle Syncs haben im Wesentlichen die gleichen Probleme wie in Punkt 3 genannt.

----------

## psyqil

 *Genone wrote:*   

> Die reine Datenmenge im Tree ist wesentlich geringer (vermutlich unter 100 MB).

 Da hast Du jetzt aber auch keine Messmethode angegeben...  :Razz: 

```
psyqil ~$ df -h /dev/hdd1

Filesystem            Size  Used Avail Use% Mounted on

/dev/hdd1             346M  187M  141M  57% /usr/portage

psyqil ~$ tar -cf portage.tar /usr/portage/*

tar: Removing leading `/' from member names

psyqil ~$ ll portage.tar

-rw-r--r--  1 psyqil users 191M Mar  2 02:43 portage.tar
```

----------

## Genone

 *psyqil wrote:*   

>  *Genone wrote:*   Die reine Datenmenge im Tree ist wesentlich geringer (vermutlich unter 100 MB). Da hast Du jetzt aber auch keine Messmethode angegeben... 

 

Doch: "vermutlich"  :Cool: 

EDIT: Um die Vermutung nochmal zu belegen:

```
$ find porttree/ -type f | xargs -i cat {} > /tmp/porttree.data; ls -l /tmp/porttree.data

-rw-r--r--  1 genone users 88238249 Mar  2 04:02 /tmp/porttree.data

$ find porttree/ | xargs -i echo {} > /tmp/porttree.names; ls -l /tmp/porttree.names

-rw-r--r--  1 genone users 5305606 Mar  2 04:06 /tmp/porttree.names

```

Und als SquashFS Dateisystem sinds hier noch ganze 22 MB, zisofs scheint nicht sonderlich für die Aufgabe geeignet zu sein da es bei meinen Tests > 200 MB belegt hat.

----------

## c07

 *Genone wrote:*   

> 3.) Der allgemeine Vorschlag des "on-demand Ebuild Fetchings" wird in naher Zukunft nicht umgesetzt, da es da ca. ne Trillion Probleme mit gibt, u.a. weil dann Syncs nicht mehr als atomar angesehen werden können, von Problemen mit Eclasses und ähnlichem mal gar nicht zu reden.

 

Ebuilds müssten halt bei substanziellen Veränderungen eine neue Revisionsnummer bekommen (was sowieso sinnvoll ist). Ansonsten müssten bei Änderungen (insbesondere KEYWORDS) die Metadaten maßgeblich sein. Ich seh da kein größeres Problem. Zwischenzeitlich nicht mehr vorhandene Ebuilds würden halt zu einem Fehler führen, aber man könnte sie auch ziemlich einfach immer einen Tag oder so länger vorhalten als die zugehörigen Metadaten (statt wie bisher umgekehrt). Eclasses müssten entweder abwärtskompatibel sein (müssen sie meistens eh), versioniert werden, oder einfach mitgesynct werden.

Abgesehn davon ist das Syncen AFAICT auch jetzt nicht wirklich atomar. Erstens durch die Commits, die zumindest praktisch nicht immer atomar sind, und wahrscheinlich auch auf der Abrufseite (was passiert, wenn sich ein --sync wegen langsamem Netzverkehr über einige Syncs auf der Masterseite erstreckt?). Zugegebenermaßen steigt natürlich die Wahrscheinlichkeit möglicher Kollisionen, deshalb wird es wichtiger, negative Folgen daraus zu begrenzen.

 *Genone wrote:*   

> 
> 
> ```
> $ find porttree/ -type f | xargs -i cat {} > /tmp/porttree.data; ls -l /tmp/porttree.data
> 
> ...

 

Da hast du noch die Informationen, die in den Inodes stecken, unterschlagen (insbesondere Timestamps)  :Wink: 

 *Genone wrote:*   

> Und als SquashFS Dateisystem sinds hier noch ganze 22 MB, zisofs scheint nicht sonderlich für die Aufgabe geeignet zu sein da es bei meinen Tests > 200 MB belegt hat.

 

Das Problem ist allerdings, dass damit der Traffic sogar noch erhöht wird. Sinnvoll ist es aber u.U. für Leute, die nicht täglich syncen.

zisofs komprimiert AFAIK nur einzelne Dateien, womit jede nach wie vor mindestens 2 KB verbraucht.

----------

## sirro

 *Genone wrote:*   

> Wer Zeit und Lust hat kann ja mal damit rumexperimentieren und den Speicherbedarf sowie Performance vergleichen und hier posten was es bringt oder kostet.

 

Da ich mich selber schon laenger fuer dieses thema interessiere kann ich hier mit Links dienen  :Wink: 

Portage in 20MB: https://forums.gentoo.org/viewtopic-t-240514.html

Platzverbrauch von Gentoo mit verschiedenen Dateisystemen: https://forums.gentoo.org/viewtopic.php?t=225745

Du hast Recht: es scheint leider kein wiederbeschreibbares Format zu geben. Zumindest habe ich bei laengerer Suche keins gefunden.  :Sad: 

----------

## Carlo

 *Genone wrote:*   

> 1.) Platzverschwendung: Vorneweg: wenn man hier mit Zahlen um sich schmeisst, bitte die Messmethode mit angeben. Der Portage Tree hat keine 500 MB, die Zahl kommt wahrscheinlich von du und sagt damit nur, wieviel Platz das Dateisystem für den Tree reserviert hat.

 

Klassische Antwort: Interessant ist, was hinten raus kommt. Ich jedenfalls habe keine Lust De-Kompressions-Schneckenrennen zu veranstalten. Snapshots in Verbinung mit adäquater Hardware mal außen vor gelassen.

----------

## hoschi

 *c07 wrote:*   

>  *Genone wrote:*   3.) Der allgemeine Vorschlag des "on-demand Ebuild Fetchings" wird in naher Zukunft nicht umgesetzt, da es da ca. ne Trillion Probleme mit gibt, u.a. weil dann Syncs nicht mehr als atomar angesehen werden können, von Problemen mit Eclasses und ähnlichem mal gar nicht zu reden. 
> 
> Ebuilds müssten halt bei substanziellen Veränderungen eine neue Revisionsnummer bekommen (was sowieso sinnvoll ist). Ansonsten müssten bei Änderungen (insbesondere KEYWORDS) die Metadaten maßgeblich sein. Ich seh da kein größeres Problem. Zwischenzeitlich nicht mehr vorhandene Ebuilds würden halt zu einem Fehler führen, aber man könnte sie auch ziemlich einfach immer einen Tag oder so länger vorhalten als die zugehörigen Metadaten (statt wie bisher umgekehrt). Eclasses müssten entweder abwärtskompatibel sein (müssen sie meistens eh), versioniert werden, oder einfach mitgesynct werden.
> 
> 

 

full ack

----------

## Carlo

 *sirro wrote:*   

> Du hast Recht: es scheint leider kein wiederbeschreibbares Format zu geben. Zumindest habe ich bei laengerer Suche keins gefunden. 

 

e2compr regt sich noch.

----------

