# Abhängigkeiten von Programmen

## manuels

Moin zusammen,

alle sagen immer, dass es nicht effizient wäre, package-binaries aus einem p2p-Netzwerk herunterzuladen um sich die Kompiler-Zeiten zu sparen, da es zu viele Möglichkeiten der Konfiguration eines Systems gibt und man so gut wie nie eine Identische finden würde.

Hab dieses Argument zwar schon verstanden, allerdings möchte ich wissen, ob es wirklich greift und nicht einfach nur so daher gesagt ist - kurz gesagt: ich will Fakten.

Hängt eine kompiliertes Programm nur von den Major-Release der Libraries ab, auf die es aufbaut? Oder gar von dem bestimmten Built, mit dem es kompiliert wurde (was ich nicht glaube).

Gibt es sonst noch Abhängigkeiten oder hängt das nur von den Libraries ab?

Vielleicht werd ich ja mal ein kleines Script basteln, das die Konfiguration von verschiedenen Rechnern sammelt und eine kleine Statistik erstellen...

Danke für Eure Antworten

Manuel

----------

## Ampheus

Bei mir gab es das Problem mit dem Rainlendar, welchen es nur als binary gibt. Dieser verlangte zwei verschiedene Versionen von libexpat.so.x. Mit einem Symlink habe ich es dann in den Griff bekommen.

----------

## XMath

Tja,

das ist dann wohl ein Problem ob gerade die Funktion, auf die in der Bib zugegriffen wird identisch mit der ist gegen die kompiliert wurde. Falls ja, geht ein symlink natürlich. Falls nein, gehts natürlich nicht. 

Ergo kann man natürlich voll auf Binaries setzen, muss dann aber darauf achten alle Bibs zu haben, welche die gewünschten Funktionen beinhalten.

My 2 cents

----------

## STiGMaTa_ch

 *manuels wrote:*   

> [...]da es zu viele Möglichkeiten der Konfiguration eines Systems gibt und man so gut wie nie eine Identische finden würde.
> 
> [...]ob es wirklich greift und nicht einfach nur so daher gesagt ist - kurz gesagt: ich will Fakten.

 

Bitte sehr

https://forums.gentoo.org/viewtopic-t-359146-highlight-.html#2570508

Ich habe mich da bereits einmal darüber ausgelassen, warum es einfach nicht möglich ist z.B. ein Binary Repository für dev-php/php-4.3.11 (heute wäre das dev-lang/php) anzulegen. Und um dir einen weiteren Fakt zu geben...

Nicht nur die USE Flags sondern auch die entsprechenden Abhängigkeiten verunmöglichen dir das. Ein einfaches Beispiel:

Ein: USE="-*" emerge -pv dev-lang/php würde mir folgendes emergen:

```
[ebuild  N    ] app-admin/php-toolkit-1.0-r2  0 kB

[ebuild  N    ] dev-lang/php-5.1.6-r6  USE="-adabas -apache -apache2 -bcmath -berkdb -birdstep -bzip2 -calendar -cdb -cgi -cjk -cli -concurrentmodphp -crypt -ctype -curl -curlwrappers -db2 -dbase -dbmaker -debug -discard-path -doc -empress -empress-bcs -esoob -exif -fastbuild -fdftk -filepro -firebird -flatfile -force-cgi-redirect -frontbase -ftp -gd -gd-external -gdbm -gmp -hardenedphp -hash -hyperwave-api -iconv -imap -informix -inifile -interbase -iodbc -ipv6 -java-external -kerberos -ldap -libedit -mcve -memlimit -mhash -ming -msql -mssql -mysql -mysqli -ncurses -nls -oci8 -oci8-instant-client -odbc -pcntl -pcre -pdo -pdo-external -pic -posix -postgres -qdbm -readline -recode -reflection -sapdb -sasl -session -sharedext -sharedmem -simplexml -snmp -soap -sockets -solid -spell -spl -sqlite -ssl -sybase -sybase-ct -sysvipc -threads -tidy -tokenizer -truetype -unicode -vm-goto -vm-switch -wddx -xml -xmlreader -xmlrpc -xmlwriter -xpm -xsl -yaz -zip -zlib" 6,328 kB

```

Wenn ich jetzt nur EIN USE Flag (sasl) hinzufüge sieht die Geschichte schon anders aus:

USE="-* sasl" emerge -pv dev-lang/php

```
Calculating dependencies... done!

[ebuild  N    ] app-admin/php-toolkit-1.0-r2  0 kB

[ebuild  N    ] dev-libs/cyrus-sasl-2.1.22-r1  USE="-authdaemond -berkdb -crypt -gdbm -java -kerberos -ldap -mysql -ntlm_unsupported_patch -pam -postgres -sample -srp -ssl -urandom" 1,571 kB

[ebuild     U ] sys-libs/db-4.2.52_p4-r2 [4.2.52_p2] USE="-bootstrap -doc -java -nocxx -tcl% -test% (-tcltk%)" 3,989 kB

[ebuild  N    ] net-nds/openldap-2.3.27-r2  USE="sasl -berkdb -crypt -debug -gdbm -ipv6 -kerberos -minimal -odbc -overlays -perl -readline -samba (-selinux) -slp -smbkrb5passwd -ssl -tcpd" 3,669 kB

[ebuild  N    ] dev-lang/php-5.1.6-r6  USE="sasl -adabas -apache -apache2 -bcmath -berkdb -birdstep -bzip2 -calendar -cdb -cgi -cjk -cli -concurrentmodphp -crypt -ctype -curl -curlwrappers -db2 -dbase -dbmaker -debug -discard-path -doc -empress -empress-bcs -esoob -exif -fastbuild -fdftk -filepro -firebird -flatfile -force-cgi-redirect -frontbase -ftp -gd -gd-external -gdbm -gmp -hardenedphp -hash -hyperwave-api -iconv -imap -informix -inifile -interbase -iodbc -ipv6 -java-external -kerberos -ldap -libedit -mcve -memlimit -mhash -ming -msql -mssql -mysql -mysqli -ncurses -nls -oci8 -oci8-instant-client -odbc -pcntl -pcre -pdo -pdo-external -pic -posix -postgres -qdbm -readline -recode -reflection -sapdb -session -sharedext -sharedmem -simplexml -snmp -soap -sockets -solid -spell -spl -sqlite -ssl -sybase -sybase-ct -sysvipc -threads -tidy -tokenizer -truetype -unicode -vm-goto -vm-switch -wddx -xml -xmlreader -xmlrpc -xmlwriter -xpm -xsl -yaz -zip -zlib" 6,328 kB

```

Jetzt musst du mir schon das Binary für dev-libs/cyrus-sasl-2.1.22-r1, sys-libs/db-4.2.52_p4-r2 und net-nds/openldap-2.3.27-r2 liefern. Das Problem ist nur, dass z.B. openldap ebenfalls wieder USE Flags besitzt (USE="sasl -berkdb -crypt -debug -gdbm -ipv6 -kerberos -minimal -odbc -overlays -perl -readline -samba (-selinux) -slp -smbkrb5passwd -ssl -tcpd") und du auch hier alle kompilierten Kombinationen anbieten müsstest. Und auch Openldap wird dadurch wieder Abhängigkeiten erzuegen und auch diese werden wiederum USE Flags haben und diese werden wieder Abhängigkeiten erzeugen u.s.w.

Reichen dir diese Argumente um zu verstehen, warum das NIE funktioniert?

Lieber Gruss

STiGMaTa

----------

## TheSmallOne

 *STiGMaTa_ch wrote:*   

> 
> 
> Wenn ich jetzt nur EIN USE Flag (sasl) hinzufüge sieht die Geschichte schon anders aus:
> 
> Jetzt musst du mir schon das Binary für dev-libs/cyrus-sasl-2.1.22-r1, sys-libs/db-4.2.52_p4-r2 und net-nds/openldap-2.3.27-r2 liefern. Das Problem ist nur, dass z.B. openldap ebenfalls wieder USE Flags besitzt (USE="sasl -berkdb -crypt -debug -gdbm -ipv6 -kerberos -minimal -odbc -overlays -perl -readline -samba (-selinux) -slp -smbkrb5passwd -ssl -tcpd") und du auch hier alle kompilierten Kombinationen anbieten müsstest. Und auch Openldap wird dadurch wieder Abhängigkeiten erzuegen und auch diese werden wiederum USE Flags haben und diese werden wieder Abhängigkeiten erzeugen u.s.w.
> ...

 

Naja, es ist ja nicht nur bei dir so, dass das Setzen dieses einen Useflags bestimmte Abhängigkeiten erzeugt, das ist ja dann schon bei jeder Person so, die das gleiche Useflag setzt. Davon ausgehend, dass Leute, die bestimmte Useflags setzen dafür auch einen Grund haben, und in ihrer Konfiguration vermutlich auch andere ähnlich gelagerte Useflags setzen, sollten die Unterschiede gar nicht so groß sein, wie man vielleicht denkt.

Davon abgesehen: Mathematisch gibt es zwar verdammt viele Möglichkeiten, aber es gibt schließlich auch viele Nutzer. Je mehr das System nutzen, desto größer ist die Wahrscheinlichkeit jemanden zu finden, der für bestimmte Pakete die gleichen Useflags benutzt.

Von daher halte ich ich die Aussage, dass es gar nicht funktionieren kann für falsch. Es ist nur, was den Aufwand zu programmieren angeht, extremst anspruchsvoll und wenig praktikabel, da es erst sinnvoll wird, wenn auch alle daran teilnehmen, und da kommt dann eben der Vertrauensfaktor hinzu: Will man wirklich Binärpakete von irgendwo auf seinem System haben?

----------

## a.forlorn

Wo das sinnvoll funktioniert, ist zB. wenn du mehr als zwei Systeme mit gleichen specs laufen hast (zwei DesktopPC). Einer kann compilieren oder beide mit distcc, aber auf einen knallst du dann die Pakete vom anderen.

----------

## STiGMaTa_ch

 *TheSmallOne wrote:*   

> Naja, es ist ja nicht nur bei dir so, dass das Setzen dieses einen Useflags bestimmte Abhängigkeiten erzeugt, das ist ja dann schon bei jeder Person so, die das gleiche Useflag setzt. Davon ausgehend, dass Leute, die bestimmte Useflags setzen dafür auch einen Grund haben, und in ihrer Konfiguration vermutlich auch andere ähnlich gelagerte Useflags setzen, sollten die Unterschiede gar nicht so groß sein, wie man vielleicht denkt.

 

Sorry, das hat mir zuviel "vermutlich", "sollten" und "vielleicht" drinn. Bring mir den Gegenbeweis, dass z.B. das Gross der Deutschen Gentoo User mehrheitlich die selben USE Flags verwendet (Globale wie auch speziell für einzelne Pakete gesetzte). Solange du mir diesen Beweis schuldig bist behaupte ich weiterhin, dass jeder einzelne Benutzer in diesem Forum andere USE Flags verwendet und niemand die selben Pakete/Abhängigkeiten wie ich besitzt  :Wink: 

 *TheSmallOne wrote:*   

> Davon abgesehen: Mathematisch gibt es zwar verdammt viele Möglichkeiten, aber es gibt schließlich auch viele Nutzer. Je mehr das System nutzen, desto größer ist die Wahrscheinlichkeit jemanden zu finden, der für bestimmte Pakete die gleichen Useflags benutzt.

 

Das stimmt natürlich zu 100%. Nur musst du das ganze Global und nicht Lokal anschauen. Vielleicht mögen du und ich die selben USE Flags beim Paket X haben, doch wer garantiert, dass dessen Abhängigkeiten und alle anderen Pakete die selben USE Flags haben? Wenn du das ganze nur für ein Paket betrachtest werden wir sicherlich einige finden die genau die selben USE Flags gesetzt haben. Aber haben wir dann auch die selbe Architektur? Und sind die anderen Pakete wirklich auf dem selben Stand?

Das Problem ist wie gesagt nicht ein einzelnes Paket sondern die Gesamtheit des ganzen Systems. Es wird schlicht und ergreifend nicht Möglich sein "ein Binary" eines Paketes zur Verfügung zu stellen, dass auf einem Grossteil der Systeme laufen wird. Alleine schon wegen der Abhängigkeiten. Natürlich kannst du hingehen und dir überlegen "Was sind sinnvolle USE Flags für den Durchschnittsuser und welches sind sinnvolle Pakete die ich anbieten könnte?". Was du dann allerdings erhältst ist genau das, was dir SuSE, RedHat und andere anbieten...

 *TheSmallOne wrote:*   

> Von daher halte ich ich die Aussage, dass es gar nicht funktionieren kann für falsch.

 

Da hast du natürlich recht. Ich ging von der Annahme aus, dass die Gentoo Developer dies zur Verfügung stellen würden. Würde das Projekt von der gesammten Community getragen wäre es sicherlich Möglich das zu realisieren. Nur behaupte ich, dass dann irgendwo ein Server wäre der Tausende unterschiedlicher Pakete hosten würde welche wahrscheinlich niemals mehr heruntergeladen werden. Irgendwann hätten wir dann mehr verwaiste als nutzbare Pakete.

Versteh mich nicht falsch, ich stehe niemandem im Wege der das ganze doch mal ausprobieren will. Ich habe hier lediglich MEINE Einschätzung dargelegt, welche wie ich finde reichlich schlüssig ist. Natürlich ist es gut Möglich, dass ich einen fundamentalen Denkfehler drinn habe. Aber es ist nicht das erste mal, dass dieses Thema diskutiert wurde. Und bisher habe ich noch kein solches "Binary Repository" gesehen. Daher denke ich, dass ich recht habe   :Cool:   :Laughing: 

Lieber Gruss

STiGMaTa

----------

## manuels

da hab ich ja mal wieder was losgetreten...

die frage ist halt, ob sich das auf wenige use-Flags konzentriert oder nich.

Das Argument, dass es das nicht tut, wollte ich nicht so einfach im Raum stehen lassen.

Ich denke das sollte man mal empirisch Untersuchen...   :Smile: 

----------

## oscarwild

 *manuels wrote:*   

> da hab ich ja mal wieder was losgetreten...
> 
> die frage ist halt, ob sich das auf wenige use-Flags konzentriert oder nich.
> 
> Das Argument, dass es das nicht tut, wollte ich nicht so einfach im Raum stehen lassen.
> ...

 

Zu den USE-Flags kommen noch die CFLAGS. Wenn man mal insgesamt annimmt, es gäbe für ein Durchschnittspaket nur 10 binäre Konfigurationsschalter (was durchaus realistisch ist), landen wir schon bei jeweils 1024 (!!!) verschiedenen Binaries. Aufgrund von Abhängigkeiten auf Systemebene, wie STiGMaTa_ch das ja bereits schön geschildert hat, wird nicht jedes dieser 1024 Pakete für jedes Zielsystem geeignet sein.

Nachdem niemand so ein Datengrab pflegen möchte, wird man den Weg gehen, redundante Kombinationen zu eliminieren, und landet damit unweigerlich, wie bei jeder Binärdistribution, auf einem Universalbinaray pro Paket, in dem die gängigen Features aktiviert wurden (auch die, die der jeweilige Anwender eigentlich gar nicht braucht), und das theoretisch auf jeder 386-kompatiblen Mühle läuft. Und da stellt man sich dann besser gleich ein suse/debian/ubuntu/... System hin.

----------

## musv

Also um das mal kurz zusammenzufassen:

Wenn du gerne Binaries mit den gebräuchlichsten Unterstützungen (USE-Flags) haben möchtest, dann gibt es dabei folgendes zu beachten. Du brauchst:

einheitliche USE-Flags, die auf allen Systemen laufen müssen, sonst wird der Aufwand zu groß (siehe Rechnung oben)

möglichst allgemeine CFLAGS. Denkbar  wäre hier: i386,(i686), PPC, die 64bit-Architekturen (kenn mich da nicht aus)

Falls Dich diese Kompromisse nicht weiter stören, solltest du eventuell mal über Ubuntu & Co. nachdenken. Apt-get erfüllt seine Installationsaufgaben auch gut, ist schneller als Portage und zuverlässig. Das soll jetzt kein Flamewar über Distributionen oder ähnliches werden. Es hat halt jede Distro ihre Vor- und Nachteile. Und die Gentoophilosophie besteht nunmal in der absoluten Konfigurationsfreiheit. Falls du das nicht brauchst, bzw. Dich das eher stört vom Zeit-/Arbeitsaufwand her, sind andere Distros vielleicht die bessere Wahl.

----------

## Klaus Meier

Also die CFLAGS sind nicht so relevant. Da ist Gentoo auch nicht wesentlich schneller oder langsamer als Ubuntu oder Debian.

Nur wenn ich sehe, welches Chaos rpm oder dep-Pakete nach kürzester Zeit auf dem Rechner anrichten, dann graut es einem nur. Da werden alle möglichen Pakete auf den Rechner gepumpt, die man später nie wieder los wird. Es ist absolut unmöglich festzustellen, welches Paket von welchem anderen noch gebraucht wird. Dann sorgen Neuinstallationen dafür, daß bestimmte Pakete überschrieben werden und Programme, die man vorher installiert hat, nicht mehr funktionieren.

Wenn man bei Fedora oder Ubuntu drei Programme installiert, die nicht in den offiziellen Repositories drin sind, dann geht irgendwas in die Hose. Das Kompilieren bei Gentoo nervt mich auch, ich hätte es auch gerne so wie bei Debian oder Ubuntu. Aber man braucht es, nicht wegen der Geschwindigkeit, sondern wegen der Konsistenz und der Flexibilität des Systems.

----------

## manuels

Arg!  :Mad: 

War ja klar, dass man missverstanden wird.  :Sad: 

Ich will keine Binärdistirbution. Ich will auch nich allen leuten vorschreiben, welche USE oder CFLAGS sie nutzen sollen.

Ich will nur untersuchen, ob das Argument wirklich greift, dass _alle_ Nutzer so unterschiedliche Konfigurationen haben.

Es könnte wirklich sein, dass sich für z.B. die Desktop-User-Gruppe das ganze auf einige (seien es auch einige Hundert) Konfigurationenen beschränkt, sodass diese _optional_ (falls solch ein Paket bereits kompiliert wurde) dieses Paket von einem anderen Nutzer über p2p heruntergeladen wird.

Sicherheitsmäßig denke ich nicht, dass es da größere Probleme gibt, als wenn man Quelltext von einer SourceForge Seite sich saugt und diesen kompiliert. Den kompletten Quelltext kann man sich sowieso nicht durchlesen.

Außerdem klappt ja schließlich auch das Wiki-Prinzip.

Aber wir schweifen ab. Wie ist das denn jetzt mit den Abhängigkeiten? Benötige ich immer genau die selbe Library-Version, gegen die ein Programm gelinkt ist? Was gibt es sonst noch für Abhängigkeiten? Dazu wurde hier noch nicht allzuviel gesagt...

Tschö mit ö

Manuel

----------

## STiGMaTa_ch

 *manuels wrote:*   

> Ich will keine Binärdistirbution. Ich will auch nich allen leuten vorschreiben, welche USE oder CFLAGS sie nutzen sollen.

 Du willst das vielleicht nicht, jedoch ist dies ein MUSS wenn du Binaries anbieten willst. Gründe siehe oben von mir, oscarwild oder musv.

 *manuels wrote:*   

> Ich will nur untersuchen, ob das Argument wirklich greift, dass _alle_ Nutzer so unterschiedliche Konfigurationen haben.

 

Wenn du wirklich etwas "untersuchen" willst, dann setz dich hin, mach einen Thread auf und bitte alle Benutzer des Deutschsprachigen Teils des Forums ihre Configs zu posten. Dann wertest du aus ob du 300 unterschiedliche oder 3x hundert ähnliche bekommst.

Oder hattest du gehofft dies nimmt dir jemand hier ab  :Laughing:  Mit diskutieren und "wenn, vielleicht oder aber" wirst du das nie "untersuchen" können...

 *manuels wrote:*   

> Es könnte wirklich sein, dass sich für z.B. die Desktop-User-Gruppe das ganze auf einige (seien es auch einige Hundert) Konfigurationenen beschränkt, sodass diese _optional_ (falls solch ein Paket bereits kompiliert wurde) dieses Paket von einem anderen Nutzer über p2p heruntergeladen wird.

 

1.) Wer sollte sich die Mühe machen tausende von Paketen zu verwalten, nur um damit zwei einsamen Gentoo Herzen auf dieser Welt eine Kompilierzeit von 5 Minuten zu ersparen? Mal ganz im Ernst manuels... wo ist da der Kosten/Nutzen Faktor???

2.) Wie bereits gesagt. Wenn DU "wissen" willst ob es so ist, mach einen Thread auf, beschreib deine Beweggründe und lass die Leute ihre Settings posten. Alles andere ist - sorry für den harten Ausdruck - Hirnwichserei !   :Cool: 

 *manuels wrote:*   

> Sicherheitsmäßig denke ich nicht, dass es da größere Probleme gibt, als wenn man Quelltext von einer SourceForge Seite sich saugt und diesen kompiliert. Den kompletten Quelltext kann man sich sowieso nicht durchlesen.

 

Na super, dann poste doch einfach mal deine USE Flags, CFLAGS und die Liste deiner Lieblingsprogramme. Lass meinen 3 Rechnern dann einige Tage Zeit und ich kompiliere dir deine Pakete frei Haus. Wundere dich dann aber nicht über "Schädlinge", "Hintertüren" oder "Trojaner" auf deinem System. 

 *manuels wrote:*   

> Außerdem klappt ja schließlich auch das Wiki-Prinzip.

 

Und wenn ich eine Melone die auf der Strasse liegt anschubse rollt die ebenfalls die Strasse entlang. Kann ich die Melone deswegen als Radersatz nutzen? Sorry, aber den Zusammenhang zwischen Sicherheit und einem Wiki sehe ich jetzt leider nicht   :Embarassed: 

Naja, wie dem auch sei... ich klinke mich jetzt aus dieser Diskussion aus. Wir hatten sie schon einmal, es gab damals schon Leute die "uns" nicht geglaubt haben und es wird auch diesmal nicht mehr als ein bisschen Diskussion in einem der unzähligen Threads dieses Forums dabei herauskommen. Falls du wider erwarten trotzdem ein Konzept heraustüftelst welches die oben genannten Probleme wiederlegt oder gar löst, dann schick mir unbedingt eine PN, damit ich der erste sein kann der dir dazu gratuliert! (Und das meine ich mit vollem ernst!)

Lieber Gruss

STiGMaTa

----------

## TheSmallOne

 *STiGMaTa_ch wrote:*   

> Würde das Projekt von der gesammten Community getragen wäre es sicherlich Möglich das zu realisieren. Nur behaupte ich, dass dann irgendwo ein Server wäre der Tausende unterschiedlicher Pakete hosten würde welche wahrscheinlich niemals mehr heruntergeladen werden. Irgendwann hätten wir dann mehr verwaiste als nutzbare Pakete.

 

Achso, ich war jetzt Aufgrund des ersten Posts von einer Art P2P-System ausgegangen, bei dem es lediglich einen Zentralen Server geben würde, der die Konfigurationen speichert und man seine Binärpakete dann direkt von jemandem zieht, der eben die gewünschte Konfiguration hat. Daher auch mein Hinweis auf das Vertrauen. In so einem Fall wäre ein Paket dann nicht mehr vorhanden, wenn niemand es mehr nutzt.

Naja egal.

----------

## franzf

Was man auch nicht vergessen darf sind speziell beim Desktopuser verschiedene Versionen aus stable und testing! (aktuell vs "stable")

Es müssten auch beide Gruppen bedient werden.

Der Nächste will compiz verwenden, und was das mal angerichtet hat... compiz brauchte cairo-1.2.*, viele andere apps brauchten die 1.0.*. entweder lief compiz ordentlich, oder eben die cairo-based apps. (glitz war da auch noch dabei)

Und das ist nur EIN Beispiel, wie sich Pakete aus unterschiedlichen Zweigen gegenseitig stören können.

Oftmals hilft hier ein neukompilieren (gegen die neuere Version) einzelner Anwendungen. Hier müssten dann auch zwei (mehr) Versionen eines Pakets mit identischen USE-Flags angeboten werden. Für einen eingefleischten Gentoo-User ein Unding...

Außerdem: kompiliert wird meist eh über Nacht (emerge -uDN world; shutdown -h now), da werd ich dann während der Arbeit auch nicht durch einen hängenden Desktop gestört (wenn der PC kein High-End-Teil ist).

Ich bin also auch recht skeptisch über den Erfolg einer rein binär strukturierten Gentoo-Installation.

Grüße

Franz

----------

## Klaus Meier

 *TheSmallOne wrote:*   

>  *STiGMaTa_ch wrote:*   Würde das Projekt von der gesammten Community getragen wäre es sicherlich Möglich das zu realisieren. Nur behaupte ich, dass dann irgendwo ein Server wäre der Tausende unterschiedlicher Pakete hosten würde welche wahrscheinlich niemals mehr heruntergeladen werden. Irgendwann hätten wir dann mehr verwaiste als nutzbare Pakete. 
> 
> Achso, ich war jetzt Aufgrund des ersten Posts von einer Art P2P-System ausgegangen, bei dem es lediglich einen Zentralen Server geben würde, der die Konfigurationen speichert und man seine Binärpakete dann direkt von jemandem zieht, der eben die gewünschte Konfiguration hat. Daher auch mein Hinweis auf das Vertrauen. In so einem Fall wäre ein Paket dann nicht mehr vorhanden, wenn niemand es mehr nutzt.
> 
> Naja egal.

 Also wenn man es sich praktisch vorstellt, dann müßtest du anstelle eines emerge einen Scan über alle verfügbaren Gentoorechner machen. Eine Datenbank nutzt dir da gar nichts, weil der entsprechende Rechner ja auch online sein muß. Dann fang schon mal vorsichtig an auszurechnen, wie viele Kombinationen es aus USE-Flags,  CFlags und CHOST gibt. Entweder macht man es dann so wie bei Debian oder Suse, wo sich die Pakete nur im CHOST unterscheiden, oder du hast mehr Kombinationen als es es Sterne in diesem Universum gibt. Und wenn die Flags mal übereinstimmen sollten, dann muß derjenige auch noch das entsprechende Paket nutzen.

Aber der Hauptgrund dagegen ist: Die Sicherheit. Wer garantiert dir, daß es keine manipulierten Pakete sind? Wie will man bei diesen Milliarden von Kombinationen Checksummen erstellen? Du installierst dir da Sachen als root. Bei Debian kommen die Pakete von genau festgelegten Servern. Hier würden sie aus nicht bekannten Quellen kommen. Und des weiteren: Ich würde keine Software auf meinen Rechner lassen, wo man ohne weiteres von außen feststellen kann, was ich auf meinem Rechner habe.

----------

## manuels

 *Quote:*   

> Du willst das vielleicht nicht, jedoch ist dies ein MUSS wenn du Binaries anbieten willst. Gründe siehe oben von mir, oscarwild oder musv. 

 

Ich will gar nichts anbieten. Schon mal was von verteilten Hashtabellen gehört? Kademlia wäre so eins.

Da muss man nichts verwalten. Jeder "schreibt" da rein, was er hat und es organisiert sich so zusagen selbst.

 *Quote:*   

> Wenn du wirklich etwas "untersuchen" willst, dann setz dich hin, mach einen Thread auf und bitte alle Benutzer des Deutschsprachigen Teils des Forums ihre Configs zu posten. Dann wertest du aus ob du 300 unterschiedliche oder 3x hundert ähnliche bekommst. 

 

Daher habe ich diesen Thread gestartet: Ich will die Grundlagen der Abhängigkeiten näher kennenlernen und nicht über den Nutzen von so einem p2p-Netzwerk diskutieren.

 *Quote:*   

> Oder hattest du gehofft dies nimmt dir jemand hier ab  Mit diskutieren und "wenn, vielleicht oder aber" wirst du das nie "untersuchen" können... 

 

Wie gesagt: Ich will hier nicht über den Sinn diskutieren. Hab ich auch nie vorgehabt, damit habt ihr angefangen.

 *Quote:*   

> 
> 
> 1.) Wer sollte sich die Mühe machen tausende von Paketen zu verwalten, nur um damit zwei einsamen Gentoo Herzen auf dieser Welt eine Kompilierzeit von 5 Minuten zu ersparen? Mal ganz im Ernst manuels... wo ist da der Kosten/Nutzen Faktor???
> 
> 2.) Wie bereits gesagt. Wenn DU "wissen" willst ob es so ist, mach einen Thread auf, beschreib deine Beweggründe und lass die Leute ihre Settings posten. Alles andere ist - sorry für den harten Ausdruck - Hirnwichserei !

 

zu 1.): Wie gesagt: Ich will hier nichts verwalten, da muss man auch nichts verwalten.

zu 2.): Vielleicht mach ich das ja auch, aber hierzu muss ich erst die Details der Abhängigkeiten kennenlernen, wozu ich _diesen_ Thread gestartet habe.

Zur Sicherheit: Da gibt es sicher ein Problem, aber hierzu muss man nachdenken und diese lösen. Und nicht einfach sagen: "Das klappt nicht", weil einen auf den ersten Blick dazu nichts einfällt.

 *Quote:*   

> Naja, wie dem auch sei... ich klinke mich jetzt aus dieser Diskussion aus.

 

Wie gesagt: Sollte nie eine Diskussion werden. Dann können wir jetzt vielleicht mal On-Topic werden...

 *Quote:*   

> Oftmals hilft hier ein neukompilieren (gegen die neuere Version) einzelner Anwendungen. Hier müssten dann auch zwei (mehr) Versionen eines Pakets mit identischen USE-Flags angeboten werden. Für einen eingefleischten Gentoo-User ein Unding... 

 Ich will hier nichts anbieten   :Mad: 

 *Quote:*   

> Ich bin also auch recht skeptisch über den Erfolg einer rein binär strukturierten Gentoo-Installation. 

 

Hiervon hab ich auch noch nie geredet.

 *Quote:*   

> Also wenn man es sich praktisch vorstellt, dann müßtest du anstelle eines emerge einen Scan über alle verfügbaren Gentoorechner machen. Eine Datenbank nutzt dir da gar nichts, weil der entsprechende Rechner ja auch online sein muß. Dann fang schon mal vorsichtig an auszurechnen, wie viele Kombinationen es aus USE-Flags, CFlags und CHOST gibt. Entweder macht man es dann so wie bei Debian oder Suse, wo sich die Pakete nur im CHOST unterscheiden, oder du hast mehr Kombinationen als es es Sterne in diesem Universum gibt. Und wenn die Flags mal übereinstimmen sollten, dann muß derjenige auch noch das entsprechende Paket nutzen. 

 Ich _weiß_, dass es zig tausend Möglichkeiten gibt. Die Frage ist nur, wie sie verteilt sind!

----------

## manuels

So und nun fangen wir mal richtig an (ich hoffe nich, dass jetzt noch Posts zur Sinn/Unsinn-Sache kommen):

Von welchen Eigenschaften sind die Pakete abhängig?

CHOST Sicher

USE auch

CFLAGS ja, aber hier kann man auch Abstriche machen. Wenn ein Paket mit allen CFLAGS kompiliert wurde, die man auch haben möchte, bis auf einem, wird man es wahrscheinlich trotzdem akzeptieren.

Libraries die es nutzt Hier ist die Major-Version natürlich wichtig. Die Frage ist aber, ob es auch von der Minor-Version abhängt.

Ich glaube, dass es nur von der Änderung der API der Library abhängt (die sich eigentlich nur mit Major-Releases ändert) - stimmt das?

Binär identisch müssen die Libraries, die man nutzen will, jedoch nicht sein, oder?

Gibt es sonst noch Aspekte, die man beachten muss?

----------

## franzf

Na gut  :Smile: 

Fang ich mal an  :Wink: 

emerge --info

```
Portage 2.1.1-r2 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r4, 2.6.18-gentoo-r2 i686)

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

System uname: 2.6.18-gentoo-r2 i686 AMD Athlon(tm) 64 Processor 3700+

Gentoo Base System version 1.12.6

Last Sync: Mon, 20 Nov 2006 21:20:01 +0000

app-admin/eselect-compiler: [Not Present]

dev-java/java-config: 1.3.7, 2.0.30

dev-lang/python:     2.4.3-r4

dev-python/pycrypto: 2.0.1-r5

dev-util/ccache:     [Not Present]

dev-util/confcache:  [Not Present]

sys-apps/sandbox:    1.2.17

sys-devel/autoconf:  2.13, 2.60

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2

sys-devel/binutils:  2.16.1-r3

sys-devel/gcc-config: 1.3.13-r4

sys-devel/libtool:   1.5.22

virtual/os-headers:  2.6.17-r1

ACCEPT_KEYWORDS="x86"

AUTOCLEAN="yes"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-march=athlon64 -O2 -pipe -msse3 -fomit-frame-pointer"

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"

CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c"

CXXFLAGS="-march=athlon64 -O2 -pipe -msse3 -fomit-frame-pointer"

DISTDIR="/usr/portage/distfiles"

FEATURES="autoconfig distlocks metadata-transfer parallel-fetch sandbox sfperms strict"

GENTOO_MIRRORS="  ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo  ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo  http://csociety-ftp.ecn.purdue.edu/pub/gentoo/"

LANG="de_DE@euro"

LC_ALL="de_DE@euro"

LINGUAS="de"

MAKEOPTS="-j2"

PKGDIR="/usr/portage/packages"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/portage /usr/local/layman/geneticone /usr/local/layman/initng"

SYNC="rsync://rsync.de.gentoo.org/gentoo-portage"

USE="x86 X aac aiglx alsa berkdb bitmap-fonts bzip2 cairo cdr cli cracklib crypt cscope cups dbus dlloader dri dvb dvd dvdr dvdread elibc_glibc emboss encode examples exif fam fbcon ffmpeg flac flash fortran gdbm gif ginac gphoto2 gpm hal iconv imagemagick initng_plugins_also initng_plugins_bash_launcher initng_plugins_chdir initng_plugins_chroot initng_plugins_conflict initng_plugins_cpout initng_plugins_critical initng_plugins_ctrlaltdel initng_plugins_daemon_clean initng_plugins_debug_commands initng_plugins_envparser initng_plugins_find initng_plugins_fmon initng_plugins_fstat initng_plugins_history initng_plugins_idleprobe initng_plugins_initctl initng_plugins_interactive initng_plugins_iparser initng_plugins_last initng_plugins_limit initng_plugins_lockfile initng_plugins_logfile initng_plugins_netdev initng_plugins_netprobe initng_plugins_ngc4 initng_plugins_ngcs initng_plugins_nge initng_plugins_pause initng_plugins_provide initng_plugins_reload initng_plugins_renice initng_plugins_rlparser initng_plugins_simple_launcher initng_plugins_stcmd initng_plugins_stdout initng_plugins_suid initng_plugins_syncron initng_plugins_syslog initng_plugins_sysreq initng_plugins_unneeded initng_plugins_usplash input_devices_keyboard input_devices_mouse ipv6 isdnlog java jpeg kde kdeenablefinal kdehiddenvisibility kernel_linux libg++ linguas_de lm_sensors mad mikmod mp3 mp4 mpeg ncurses nls nptl nptlonly nsplugin nvidia odbc ogg openal opengl pam pcre perl png ppds pppd python qt3 qt4 quicktime readline reflection scanner sdl session spell spl sqlite ssl svg tcpd tetex theora tiff truetype truetype-fonts type1-fonts udev unicode userland_GNU vcd video_cards_fbdev video_cards_nv video_cards_nvidia vorbis win32codecs x264 xcomposite xine xml xml2 xorg xscreensaver xv xvid xvmc zlib"

Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
```

/etc/portage/package.use (Inhalt aller Files)

```
app-doc/doxygen doc

dev-cpp/clucene strigi threads

dev-lang/python doc

dev-util/kdevelop clearcase graphviz pascal subversion

kde-misc/strigi -dbus -inotify -log4cxx

media-libs/win32codecs real

media-libs/xine-lib asf

media-libs/tse3 oss

media-libs/tse3 arts -oss

media-video/kmplayer mplayer

x11-libs/qt doc sqlite

x11-libs/cairo X pdf

app-portage/geneticone doc

dev-games/irrlicht doc

dev-python/PyQt doc

dev-python/pykde doc

kde-base/kdelibs arts

kde-base/pykde doc

media-gfx/gwenview kipi

media-gfx/sane-backends usb

media-sound/lilypond vim

media-sound/noteedit arts

sys-apps/initng-ifiles net runlevels vim fixes

sys-apps/initng service_cache
```

package.keywords / ~.mask lass ich hier mal lieber  :Wink: 

Der Kommentar oben war nicht so sehr auf dich bezogen (@manuels), ich wollt einfach diesen Punkt auch noch los werden, da das zu zusätzlichen Komplikationen bei der Erstellung von Binär-Paketen für Gentoo führt.

Grüße

Franz

----------

## franzf

 *manuels wrote:*   

> Libraries die es nutzt Hier ist die Major-Version natürlich wichtig. Die Frage ist aber, ob es auch von der Minor-Version abhängt.

 

Bei Cairo war es auch die Minor-Release (1.0 -> 1.2), welches zu Problemen geführt hat. Speziell Projekte, welche noch in recht frühem Stadium sind und sich schnell entwickeln, ändern auch häufig die API während Minor-Releases (->GStreamer, drum unterstützen die letzten Amaroks diesen nicht).

 *Quote:*   

> Ich glaube, dass es nur von der Änderung der API der Library abhängt (die sich eigentlich nur mit Major-Releases ändert) - stimmt das?
> 
> Binär identisch müssen die Libraries, die man nutzen will, jedoch nicht sein, oder?

 

Grundsätzlich ist die API entscheidend. Allerdings gibts da noch die ABI (http://de.wikipedia.org/wiki/Binärschnittstelle <-werd daraus nicht unbedingt schlau; kann da wer was zu sagen?), was bei der Änderung von xorg-7.0 auf 7.1 Probleme mit den Binär-Grafikkarten-Treibern verursachte.

----------

## Fauli

Das ABI gibt bei C++-Programmen z. B. an:wie die Tabellen mit den virtuellen Funktionsadressen (vtables) aussehen müssen,wie die Typinformationen (RTTI) binär aussehen müssen,wie Exceptions auf dem Stack abgelegt werden,wie das Name Mangling funktioniertusw.Diese Dinge müssen natürlich im Programm und in der verwendeten Bibliothek gleich sein. Wenn sich das zwischen verschiedenen Compiler-Versionen ändert, funktionieren die Bibliotheken, die mit dem älteren Compiler übersetzt wurden, nicht mehr mit den Programmen zusammen, die mit dem neueren Compiler übersetzt wurden (und umgekehrt).

----------

## Klaus Meier

 *manuels wrote:*   

> So und nun fangen wir mal richtig an (ich hoffe nich, dass jetzt noch Posts zur Sinn/Unsinn-Sache kommen)

 Na dann fang mal an. Entschuldige, daß ich mir ernsthaft Gedanken über deinen Post gemacht habe. Und ich bete, daß du der geniale Crack bist, der mich von allen Streß befreit, den ich mit Gentoo habe. Jedenfalls kann ich dir nicht ansatzweise das Wasser reichen.

----------

## manuels

Gut, mach ich.   :Rolling Eyes: 

Zur Sache:

Also ist die Compiler-Version für ein Paket auch wichtig. Gibt es ein Tool, das mir die ABI-Version ausspuckt?

----------

## manuels

Noch ne kurze Frage: Wenn ich eine Bibliothek A habe, die das USE-Flag U hat, und ich ein Programm B habe, das dieses USE-Flag U nicht nutzt (also nicht nicht gesetzt hat, sonder für das es überhaupt nicht definiert ist).

Kann dann das Programm B, das gegen A mit (bzw. ohne) dem USE-Flag U kompiliert wurde, auch mit einer Version von A laufen, das ohne (bzw. mit) dem USE-Flag U kompiliert wurde (ich also im nachhinein die Version von A ersetze)?

Hoffe, ihr rafft, was ich meine...

Tschö mit ö

Manuel

----------

## moe

Ich denke nicht, speziell bei apache und php ist es ja so, dass der Apache bestimmte USE-Flags bei php voraussetzt, bzw. sogar je nach seinen eigenen USE-Flags bestimmt USE-Flags bei PHP voraussetzt oder blockiert..

----------

## manuels

Echt? Meinst du, dass wenn für Apache USE-Flag 1 gesetzt ist, dies zu folge hat, dass PHP USE-Flag 2 benötigt, oder dass PHP dann auch USE-Flag 1 benötigt?

----------

## ChrisJumper

Hi manuels,

ich kann mich leider nicht zurückhalten und muss unbedingt noch was zu deinem Thread schreiben.

Natürlich haben sich über diese Idee schon viele den Kopf zerbrochen und ich denke auch das sie nur noch nicht "richtig" angepackt wurde.

Wenn du ein Analyse-Tool schreiben willst das dir diese Daten sucht, dann würde ich folgendes Versuchen: All die von dir benötigten Informationen liegen bereits im Portag-Tree, vergraben in diversen Abhängigkeiten. Vielleicht gelingt es dir ja ein Programm/Skript zu erstellen das diese Einstellungen durchgeht und sammelt, Analysiert.

Versuche "emerge" aufzuboren, stelle die richtigen Fragen an der richtigen Stelle. Gemeind ist bei den Leuten die Ahnung davon haben. Vielleicht machst du sie auf dich aufmerksam wenn du dein Vorhaben geschickter in Worte kleidest und deine Vorstellung, Frage oder Theorie noch ein wenig ausarbeitest.

Für das "erste" bist du doch nicht an Live-Daten gebunden oder? Aber ich bin mir sicher das du Anhand einer voranalyse schon diverse Hotpots finden könntest die einen tieferen Blick wert sind. Vielleicht gelingt es dir mit einem Virtuellen System und sehr viel Rechenpower diese Frage zu klären.

Nun aber nochmal zu dem Punkt den du nicht mehr hören wolltest: Sinn oder Unsinn. Ein Problem auf das du zwangsläufig stoßen wirst ist das der Computer vorher noch nicht weiß wie das fertige Paket aussieht. Und daher auch nicht vergleichen kann ob jemand anders das Paket schon hat.  (Sofern das irgendwann mal eine Absicht ist).

Ist das fertige Paket vielleicht mehr als einfach die Summe seiner Abhängigkeiten? Denk doch mal daran das man den neuen C-Compiler 2 mal bauen sollte damit er seine volle Leistung entfaltet... oder einfach an all die Compilerfehler die dir schon über den Weg gelaufen sind, nur weil Protage nicht berücksichtigen konnte das Kernteile noch nicht mit newuse nachgerüstet wurden.

Bei all den Gedanken vermute ich das die Prüfung aller Abhängigkeiten und die Suche nach evt. gleichen Mustern zu gross wird. Bzw. das sie in einer solch kleinen Menge von Gentoo-Nutzern nahezu "unendlich" wären. Mehr sinn macht es dann eher gleiche Muster zu finden. Und damit zu arbeiten. Aber genau das macht Portage.

Nochwas zur vorherigen Fragen:

 *Quote:*   

> Echt? Meinst du, dass wenn für Apache USE-Flag 1 gesetzt ist, dies zu folge hat, dass PHP USE-Flag 2 benötigt, oder dass PHP dann auch USE-Flag 1 benötigt?

 

Natürlich aber eben nicht unbedingt. Stell dir Folgende Situation vor:

Es ist ein Useflag das die Abhängikeit 1 mit sich bringt. Aber in Apache evt. garnicht erwähnt wird weil es keine Teilmenge deren potentiellen Useflags ist. Dann könnte es aber durchaus sein das dies aber eine Teilmenge von den php-Useflags ist, weil hier das feature unsterstützt wird.

(Und nein, mir fallen keine bestimmten Beispiele dazu ein, aber theoretisch muss man das schon berücksichtigen wenn es hinreichend wahrscheinlich ist).

Tipp: Versuche nicht nur mit Hash-Tabellen zu arbeiten sondern mit sortierten Mustern und Vektoren, diese kann man wenigstens Mathematisch "einfacher" vergleichen.

----------

## firefly

Das wir jetzt Offtopic:

 *ChrisJumper wrote:*   

> Denk doch mal daran das man den neuen C-Compiler 2 mal bauen sollte damit er seine volle Leistung entfaltet... 

 

tut mir leid das ist aber schwachfug. Beim übersetzten des GCCs wird ein 3-way bootstrap durchgeführt. Sprich bei einem

"emerge gcc" übesetzt sich der "neue" GCC mit sich selbst.

Wenn ich das richtig verstanden habe läuft das ganze in etwa so ab:

Schritt 1: Der "neue" GCC wird mit dem "alten" GCC übersetzt (das binary hat dann den namen xgcc).

Schritt 2. Dieses Komplilat wird dann verwendet um dann den C-Compiler (gcc) nochmals mit sich selbst zu übersetzten.

und am Schluss (3. Schritt)  werden dann die anderen komponenten (c++/fortran und co.) mit dem "neuen" gcc übersetzt.

Ein paar mehr infos gibts auch hier:

https://forums.gentoo.org/viewtopic-t-506702-highlight-gcc+bootstrap.html

----------

## moe

Ich hab jetzt keine Lust das nochmal auszuprobieren, aber ich glaube es hing bei Apache mit dem USE-Flag threads oder nicht zusammen. Wenn Apache threaded gebaut ist, muss auch PHP threaded sein, und im Apache muss irgendein bestimmtes MPM per Useflag aktiviert sein.

Lies doch mal die ebuilds von dev-lang/php und net-www/apache, da müsste es sogar im Klartext bei den Ausgaben des ebuilds drinstehen..

----------

## Carlo

 *manuels wrote:*   

> Ich will gar nichts anbieten. Schon mal was von verteilten Hashtabellen gehört? Kademlia wäre so eins.
> 
> Da muss man nichts verwalten. Jeder "schreibt" da rein, was er hat und es organisiert sich so zusagen selbst.

 

Das Problem dabei ist die fehlende Vertrauenswürdigkeit. Die Wahrscheinlichkeit, sich keinen Trojaner via p2p zu saugen, geht gegen Null.

----------

## manuels

 *Quote:*   

> Das Problem dabei ist die fehlende Vertrauenswürdigkeit. Die Wahrscheinlichkeit, sich keinen Trojaner via p2p zu saugen, geht gegen Null.

 

Jo, wie gesagt. Da müsste man ein bisschen Hirnschmalz investieren.

Das mit den impliziten USE-Flags macht mir aber zur Zeit am meisten Kopfschmerzen...

----------

## moe

Hab just n Beispiel dazu gefunden:

```
>>> Emerging (5 of 38) x11-libs/gtk+-2.10.6 to /

 * gtk+-2.10.6.tar.bz2 MD5 ;-) ...                                        [ ok ]

 * gtk+-2.10.6.tar.bz2 RMD160 ;-) ...                                     [ ok ]

 * gtk+-2.10.6.tar.bz2 SHA1 ;-) ...                                       [ ok ]

 * gtk+-2.10.6.tar.bz2 SHA256 ;-) ...                                     [ ok ]

 * gtk+-2.10.6.tar.bz2 size ;-) ...                                       [ ok ]

 * checking ebuild checksums ;-) ...                                      [ ok ]

 * checking auxfile checksums ;-) ...                                     [ ok ]

 * checking miscfile checksums ;-) ...                                    [ ok ]

 * checking gtk+-2.10.6.tar.bz2 ;-) ...                                   [ ok ]

 * Please re-emerge x11-libs/cairo with the X and pdf USE flag set
```

----------

## think4urs11

Eigentlich ist es doch ganz simpel

Um das Ziel zu erreichen braucht es (mindestens) folgendes

a) portage müßte erweitert werden in einer Weise wie Microsoft das mit seinen Updates macht (u.a. heißt das es ist nicht optional sondern fest verdrahtetes Verhalten)

d.h. es müßte bei einem emerge sync das System analysiert werden und die Infos von emerge info, /etc/portage/package.* und ggf. weiterer eingesammelt werden

b) damit diese Infos anonymisiert aber eindeutig zuordenbar sind erfolgt eine Verknüpfung mit IP-Adresse, MAC, CPU-ID und einem Hash über die eingebaute Hardware

c) dies wird nun als 'thatsme.txt' an den Updateserver geschickt wo alles zusammenläuft

d) der Server analysiert nun die Kombination und bildet daraus einen SHA512 der zukünftig als eindeutiger Index dient um passende Pakete wiederzufinden

e) der Server bietet -sofern vorhanden- die Updates in binärer Form an; im anderen Fall wird normal kompiliert und das Kompliat danach zum Server übertragen der es (siehe a-d) in seine DB einfügt

f) Rechner die selbst compilen übertragen auch immer einen SHA mit; erst wenn dieser von einer zu bestimmenden Anzahl von PC identisch einläuft ist das Binary als 'safe' zu betrachten um eingeschmuggelte Trojaner zu finden

(natürlich klappt das nicht wenn $blackhat den Trojan bereits im Source plazieren konnte, hierfür ist zusätzlich eine Hashprüfung der Sourcen gegen upstream notwendig)

g) die DB wird regelmäßig gesäubert z.B. von Minibinaries die auch direkt übersetzt werden können weil es zeitlich ähnlich schnell geht

h) ...

Auf diese Art würde die DB automatisch in relativ kurzer Zeit ziemlich vollständig bestückt sein.

Ein Plattensystem im mittleren zweistelligen TB-Bereich sollte grob überschlagen eigentlich genügen um den größeren Teil der 'in the wild Varianten' damit aufzufangen. Natürlich ist es trotzdem sinnvoll ein wesentlich größeres Plattensystem (~ 1PB] zu hosten da spätestens mit dem nächsten gcc-Release alles mögliche 'neu' aufschlägt.

Weiterhin ist zu definieren wie lange ältere Binaries vorgehalten werden sowie diverse andere Kleinigkeiten, so z.B. die kryptografische Sicherheit die eingebaut werden sollte um eine Kompromittierung des Systems wirksam zu unterbinden - mir schwebt da etwa vor über cacert.org signierte Zertifikate an die User zu verteilen; Ausweisdaten und public key werden 'für den Fall der Fälle' bei einem Notar hinterlegt.

(Problem: was tun in Ländern ohne Ausweispflicht? Sozialversicherungsnummer ggf.?)

Natürlich läßt sich das auch als P2P aufspannen allerdings steigt der Programmieraufwand damit erheblich an.

Oder kurz gesagt:

Um wirklich spürbaren Nutzen zu bringen ohne die Flexibilität der Nutzer zu weit einzuschränken wäre der Aufwand enorm und von einer non-profit-Org. unmöglich zu stemmen. Stark vereinfachte Varianten sind hingegen entweder zu unflexibel oder schlicht nutzlos.

wer Ironie findet .........   :Rolling Eyes: 

----------

## Klaus Meier

Hallo Think4UrS11,

du hast aber schon gelesen, daß der Threadstarter niemanden haben möchte, der sagt, aus welchem Grund es nicht geht.

----------

## think4urs11

 *Klaus Meier wrote:*   

> du hast aber schon gelesen, daß der Threadstarter niemanden haben möchte, der sagt, aus welchem Grund es nicht geht.

 

warum wohl habe ich denn geschrieben was alles notwendig wäre um das Ziel des Threadstarters zu erreichen?

Es wird nunmal etwas in der Art a-h) gebraucht damit dieses Ziel vernünftig umgesetzt werden kann (es sei denn natürlich dir oder jemand anderem fällt eine andere Lösung ein die das alles auch ähnlich umfassend abdeckt was/wie die nötigen Infos zusammengetragen und analysiert werden). Natürlich muß an den Details erst noch gefeilt werden aber im groben sollte das die Anforderungen abdecken.

Das ich als Fazit aus meiner Sicht ein 'ist kaum realisierbar' daruntersetzte darfst du gerne meinem Recht auf freie Meinungsäußerung zuschreiben.

Aus meiner ganz persönlichen Sicht ist das schlicht ein Projekt das für die relativ kleine Gemeinde der Gentoo-Devs nicht in einem vernünftigen Zeitrahmen machbar ist.

Was ich vorhin allerdings noch vergessen hatte war wie mit Maschinen umzugehen sein wird die Software an Portage vorbei installiert haben. Dies kann ja zu nicht lösbaren Konflikten führen (z.B. weil sich jemand spezielle Patches in glibc eingebaut hat o.ä.)

----------

