jug
Ehemalige
Anmeldungsdatum: 19. März 2007
Beiträge: 12335
Wohnort: Berlin
|
eierl.Wollmilchsau schrieb: Ich glaube, ihr habt das nicht ganz verstanden.
In der Kommunikation gibt es kein „nicht verstanden“ nur ein „schlecht erklärt“. 😉 Nein, ernsthaft, versuche es anders zu erklären, irgendwas ist in deinem Kopf drin, so dass das Thema für dich einen Sinn ergibt – eine Information die mir fehlt und deshalb kann ich deinen Gedankengängen nicht folgen.
Einer „neuen Art von Abhängigkeiten“ bedürfte es aber dennoch, damit nicht bei der Installation die Abhängigkeiten nicht aufgelöst werden können würden.
Du willst bei der Installation eines Paketes die Abhängigkeiten nicht auflösen? Und wie soll das Programm dann funktionieren? Es braucht die Abhängigkeiten um überhaupt funktionieren zu können (daher der Name „abhängig“). Wenn du die nicht auflöst, dann installierst du ein Programm unvollständig und es funktioniert nicht. Das ist komplett sinnlos.
Fragt sich nur noch, wie die automatische Mitinstallation, aber nicht Deinstallation(das geschieht dann mit autoremove) der enthaltenen Pakete gelöst werden möchte.
So wie es die Paketverwaltung jetzt schon macht? Wirklich, ich lese das was du schreibst und alles was ich dabei denke ist: er beschreibt die Paketverwaltung, genau so, wie sie jetzt gerade funktioniert, glaubt aber dass seine Lösung anders/besser ist … und es ergibt für mich keinen Sinn. ~jug
|
eierl.Wollmilchsau
(Themenstarter)
Anmeldungsdatum: 24. Juli 2014
Beiträge: Zähle...
|
Die „neue Art von Abhängigkeiten“ habe ich oben schon beschrieben. Sie werden bei der Installation ignoriert, da die Abhängigkeit ja als Paket im Paket mitgebracht wird, daher automatisch entpackt und installiert wird. Das mitgebrachte Paket wird sofort als "Abhängigkeit"( apt-mark auto ) markiert, damit es, sobald es nicht mehr benötigt wird, beim nächsten apt-get autoremove entfernt wird. Die Abhängigkeiten, die ja bei der Installation ignoriert wurden, sind lediglich dafür zuständig, dass das nun als automatisch installiert markierte Paket weiterhin benötigt wird und nicht beim nächsten apt-get autoremove wieder entfernt wird. Beim Entfernen werden die mitgebrachten Pakete natürlich nicht automatisch mitentfernt, aber wenn kein anderes Paket sie mehr benötigt, beim nächsten apt-get autoremove Um es nochmal etwas verständlicher zu machen: Es wäre eigentlich alles wie gehabt, nur die Pakete würden ihre Bibliotheken usw., die sie vorher als "echte" Abhängigkeiten mitgebracht haben, selbst sozusagen als „Paket im Paket“ mitbringen. Diese Pakete werden natürlich automaisch installiert und als automatisch installiert(apt-mark auto) markiert. Dass dein eintraditionelles Auflösen der Abhängigkeiten sinnlos wäre, liegt auf der Hand.
|
Developer92
Anmeldungsdatum: 31. Dezember 2008
Beiträge: 4101
|
eierl.Wollmilchsau schrieb: Um es nochmal etwas verständlicher zu machen: Es wäre eigentlich alles wie gehabt, nur die Pakete würden ihre Bibliotheken usw., die sie vorher als "echte" Abhängigkeiten mitgebracht haben, selbst sozusagen als „Paket im Paket“ mitbringen.
D.h. du erzeugst einen zusätzlichen Layer an Komplexität welcher zudem wesentlich mehr Bandbreite bei Updates braucht und schwerer zu implementieren ist um ein Problem zu lösen welches nicht existiert? Interessant.
Diese Pakete werden natürlich automaisch installiert und als automatisch installiert(apt-mark auto) markiert. Dass dein eintraditionelles Auflösen der Abhängigkeiten sinnlos wäre, liegt auf der Hand.
Siehe oben. Nachtrag: Bedenke zudem auch so Dinge wie Trust-Level, Signaturen, etc.
|
jug
Ehemalige
Anmeldungsdatum: 19. März 2007
Beiträge: 12335
Wohnort: Berlin
|
eierl.Wollmilchsau schrieb: Sie werden bei der Installation ignoriert, da die Abhängigkeit ja als Paket im Paket mitgebracht wird, daher automatisch entpackt und installiert wird. Das mitgebrachte Paket wird sofort als "Abhängigkeit"( apt-mark auto ) markiert, damit es, sobald es nicht mehr benötigt wird, beim nächsten apt-get autoremove entfernt wird.
Ok, soweit habe ich das schon verstanden. Du willst deb-Pakete quasi rekursiv ineinander verschachteln, so dass jedes Paket seine Abhängigkeiten mit bringt. Nur ist für mich „mit installieren weil mitgebracht“ kein ignorieren. Das Paket wird ja trotzdem installiert und eben nicht ignoriert. Wie das Paket der Paketverwaltung zugespielt wurde ist fast schon unerheblich. Die Idee kommt meiner Meinung nach auch mit ein paar Problemen.
Du hast die Downloads einfach zusammen geklebt. Egal wie viele Pakete die libZ benötigen, sie alle müssen eine libZ.deb in ihrem Programm.deb mitliefern. Da solche Bibliotheken potentiell von hunderten von Programmen genutzt werden, müssten hunderte von Paketen die libZ.deb mit herunterladen, selbst wenn diese längst installiert ist. Das verschwendet viel Bandbreite bei den Nutzern und den Betreibern der Paket-Repositories. Wenn die libZ mal aktualisiert wird, zum Beispiel bei einem Sicherheitsupdate müssen ALLE Pakete angepasst werden, die die libZ enthalten, die erscheinen mit neuen Paketnummern in den Repositories und die Paketverwaltung fängt an JEDES Paket neu runter zu laden (anstatt einmal die libZ zu laden). Damit wären wir wieder bei 1. Was machst du wenn ein Maintainer sein Paket später aktualisiert? Das ist dann das einzige Programm in dem eine Sicherheitslücke noch drin ist, weil das Paket hängt ja von einer älteren Version der libZ ab, weshalb die ältere Version drauf bleibt solange noch Pakete davon abhängen. Das heißt, alle Pakete die davon abhängen bleiben unsicher. Schlimmer noch, was ist, wenn ein Paket einfach eine libZ mitliefert, die mit anderen Paketen der Distribution inkompatibel ist und die Version der Distribution einfach ungefragt überschreibt … dann fliegt dir das Ding um die Ohren (ok, das hat man bei Fremdquellen häufig auch). Das hat auch was mit Vertrauen zu tun (vgl. Eine kleine Geschichte über fremde Paketquellen)
Vor allem aber ist für mich die zentrale Frage bei der ganzen Diskussion – welchen Vorteil versprichst du dir davon, die Abhängigkeiten so zu verschachteln?
Ich meine, der Unterschied besteht doch lediglich in einem „oh, und ich brauche noch die libxml++2.6 , installiere die bitte aus dem Repository.“ anstatt einem „installiere bitte auch das hier angehängte libxml++2.6.deb “. Und wenn das der einzige Unterschied ist, dann verstehe ich nicht, was dabei besser sein soll die Downloads der Abhängigkeiten zu einem riesigen Blob zusammen zu kleben. Genau für diese Aufgabe ist die Paketverwaltung doch da! Genau das macht sie am besten! Erklärt hast du es jetzt, und ich glaube ich habe es verstanden, nur die Motivation dahinter ist mir nicht klar. Der Rest den du beschreibst unterscheidet sich wie gesagt nicht von dem, was die Paketverwaltung so oder so schon macht. ~jug
|
juifeng
Anmeldungsdatum: 16. April 2006
Beiträge: 159
Wohnort: Augsburg
|
Ich *glaube*, dass das Problem, das mit dieser Idee gelöst werden soll, folgendes ist: Wenn man irgendwo ein deb-Paket auftreibt (von irgendwo heruntergeladen, von einer anderen Distro/-Version, …) und installieren will, scheitert das oft daran, dass in der aktuellen Distro-Version nicht mehr alle Abhängigkeiten enthalten sind. Wenn das Paket diese dann einfach selbst mitbringt, ist das kein Problem. Allerdings wurden die zahlreichen Nachteile ja schon genannt. Es ist ja auch nicht sicher, dass eine "libbla5"-Abhängigkeit bei Debian genau das gleiche beinhaltet wie bei Ubuntu oder Mint, trotzdem könnte ein Mint-System nach der Installation eines Ubuntu-Pakets, das libbla5 enthält, denken, dass es die Mint-libbla5 bereits installiert hat, obwohl es "nur" die Ubuntu-Version ist. Ich denke auch, dass hier kaum Vorteile, dafür jede Menge Nachteile entstehen. Wer ein Paket haben will, das in möglichst vielen Distros funktioniert, muss möglichst viele Abhängigkeiten statisch linken (so dass die Bibliothek quasi direkt in der ausführbaren Datei enthalten ist) oder die .so-Dateien der Bibliotheken im Paket mitbringen, in ein eigenes Verzeichnis entpacken, und dann zur Laufzeit diese Bibliotheken laden (über Setzen von LD_LIBRARY_PATH bei der Ausführung oder Setzen von rpath beim Linken).
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
eierl.Wollmilchsau schrieb: Beim Entfernen werden die mitgebrachten Pakete natürlich nicht automatisch mitentfernt, aber wenn kein anderes Paket sie mehr benötigt, beim nächsten apt-get autoremove
Ich möchte dahingehend nochmal erwähnen, dass aptitude dies entgegen apt-get sehr wohl automatisch macht. Einer der Gründe, warum ich aptitude bevorzuge. ♥ juifeng schrieb: Ich denke auch, dass hier kaum Vorteile, dafür jede Menge Nachteile entstehen. Wer ein Paket haben will, das in möglichst vielen Distros funktioniert, muss möglichst viele Abhängigkeiten statisch linken (so dass die Bibliothek quasi direkt in der ausführbaren Datei enthalten ist) oder die .so-Dateien der Bibliotheken im Paket mitbringen, in ein eigenes Verzeichnis entpacken, und dann zur Laufzeit diese Bibliotheken laden (über Setzen von LD_LIBRARY_PATH bei der Ausführung oder Setzen von rpath beim Linken).
Genau, das Problem, so wir es inzwischen richtig verstanden haben, ist also schon heute lösbar und betrifft nur wenige Pakete aus Fremdquellen (ob wirkliche Repositories oder „nur“ händisch heruntergeladen). Das Paketverwaltungs-Prinzip löst genau die von jug beschriebenen Probleme sehr elegant und ist im Einzelfall durch statische Verlinkung oder der von juifeng beschriebenen Methode über LD_LIBRARY_PATH bereits umgehbar, ohne das Prinzip selbst auszuhebeln oder zu erweitern. Auf alle Fälle eine sehr interessante Diskussion, ich bin auf eierl.Wollmilchsaus nächste Anwort gespannt. 👍
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12828
|
eierl.Wollmilchsau schrieb: Eigentlich war das nur eine Idee, wie man "traditionelle" Abhängigkeiten verweiden und trotzdem dafüt sorgen könnte, dass die benötigte Software nicht x-mal installiert und in den RAM geladen wird.
Das ist der Punkt: das geht prinzipiell nicht. Entweder man sorgt dafür, dass ein Paket nur ein Mal im System installiert ist - oder halt nicht. Beides gleichzeitig geht nicht. Insbesondere ist es überhaupt nicht sinnvoll, wenn dieselbe Version X eines Paketes Y auf zwei Wegen auf das System kommen kann, aber nur eine der beiden Kopien installiert ist. Prinzipiell können beide Programme A und B das Paket Y in Version X mitbringen, aber die beiden Pakete von Y gleichen einander nicht, obwohl sie die selbe Versionsnummer X haben. Dann hängt es von der Reihenfolge der Installation ab, welches Y im System installiert ist - und welches der beiden Programme A oder B ggf. ein Problem bekommt. Selbst, wenn die beiden Y gleich sind, vervielfacht man den Aufwand der Wartung von Y unnötig: denn dann bräuchte es eigentlich nur einen Maintainer (so, wie es heute ja ist). Der ganze Ansatz hat nur Nachteile. Und dabei bin ich noch gar nicht auf das erhöhte Downloadvolumen eingegangen... Nein, wenn Programme ihre Version eines Paketes mitbringen, dann sollten sie sie auch nur selbst nutzen. Alles andere macht keinen Sinn.
|