Benno-007
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
Viel schöner ist, dass dann beim nächsten Aufruf von Firefox für jede Language-Pack-XPI ein eigenen Fenster mit "Installieren/Ablehnen"-Dialogen geöffent wird. Zumindest bei dem Original-FreeBSD-Paket.
Dann kommt FreeBSD entgegen meiner Annahmen doch mehr an Win als an Arch ran. 🤓
|
Naubaddi
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 744
|
Hi, eierl.Wollmilchsau schrieb: ..."wie scheiße" Linux ist...
und wo ist das Problem, soll Er doch nehmen was besser ist. Jede jeck es anders 😉. Habe gerade auch so ein ähnliches Problem mit meiner ehemaligen Verlobten, und das nur weil die Industrie es nicht schafft vernünftige Gabeln zu produzieren mit der man Suppe gabeln kann. Und meine ehemalige Verlobte unterstützt das auch noch und versucht mir kontinuierlich einen Löffel unter zu schieben. Duck und wech 😉 Grüßle
|
Benno-007
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
Löffelchen...? Achso, falsches Forum. 😳 Es geht hier ja um Abhängigkeiten. Also im Linux-Bereich.
|
eierl.Wollmilchsau
(Themenstarter)
Anmeldungsdatum: 24. Juli 2014
Beiträge: Zähle...
|
OT: Ich will nicht nicht deine ehemalige Verlobte sein...
HELAU HELAU HELAU, uups dreifach donnernd hab ich vergessen.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12822
|
eierl.Wollmilchsau schrieb:
Unter OS X und Windows gibt es keine Paketverwaltung, geschweige denn ein automatisches Auflösen von Abhängigkeiten. Sicherlich muss man auch hier mal das eine oder andere extra installieren aber es ist doch sehr selten.
Meine Frage daher:
Auch wenn es nicht direkt mit GNU/Linux zu tun hat, wie wird das Problem denn unter den eben genannten Betriebssystemen gelöst?
Soweit ich weiß, ist die Lösung bei Apple, dass alle / die meisten benötigten Bibliotheken mit dem Programm zusammen installiert werden. Das hat immerhin den Vorteil, dass man sicher sein kann, dass immer ein bekannter und idealerweise getesteter Stand zum Einsatz kommt. Mit Paketverwaltungen wie bei Linux Distributionen üblich, kann es im Prinzip passieren, dass ein Update einer Bibliothek ein Programm dysfunktional macht. Beide Ansätze haben ihre Vor- und Nachteile.
|
eierl.Wollmilchsau
(Themenstarter)
Anmeldungsdatum: 24. Juli 2014
Beiträge: 144
|
Obwohl Linux hier prinzipiell im Vorteil ist, denn im Gegensatz zu OS X / Windows bietet es theoretisch eine Paketverwaltung an; keiner ist gezwungen, sie zu benutzen.
|
jug
Ehemalige
Anmeldungsdatum: 19. März 2007
Beiträge: 12335
Wohnort: Berlin
|
eierl.Wollmilchsau schrieb: Obwohl Linux hier prinzipiell im Vorteil ist, denn im Gegensatz zu OS X / Windows bietet es theoretisch eine Paketverwaltung an; keiner ist gezwungen, sie zu benutzen.
Richtig, kein Hersteller ist gezwungen die Paketverwaltung zu nutzen. Viele Vorteile vor allem für die Anwender (zum Beispiel zentrale Upgrades) bietet es aber dennoch. Außerdem warnen wir immer wieder vor Software aus Fremdquellen. rklm schrieb: Mit Paketverwaltungen wie bei Linux Distributionen üblich, kann es im Prinzip passieren, dass ein Update einer Bibliothek ein Programm dysfunktional macht.
Angenommen, dass sämtliche Software aus den offiziellen Paketquellen stammt, dann wäre das ein Bug den die Paketmaintainer/der Distributor zu beheben haben. Andernfalls dürfte davon höchstens Software aus Fremdquellen betroffen sein. Eigentlich ein Grund für die Entwickler von Software in die offiziellen Paketquellen aufgenommen zu werden anstatt etwas eigenes zu basteln. ~jug
|
eierl.Wollmilchsau
(Themenstarter)
Anmeldungsdatum: 24. Juli 2014
Beiträge: 144
|
Hätte da so eine Idee:
Zunächsteinmalbräuchte es eine „neue Art von Abhängigkeiten“, diese Abhängigkeiten werden bei der Installation nicht beachtet, aber bei einer potenziellen Deinstallation der Abhängigkeits selbst, nicht des Hauptpaketes, weigert sich die Paketverwaltung die Abhängigkeit zu deinstallieren, wenn sie noch von einem anderen Paket benötigt wird.
Jedes Paket bringt seine Abhängigkeiten selbst mit, aber nicht als eigenständige Kopie, a la OS X/Windows, sondern als eigenständiges Paket in den eigen Paketinhalten. Wenn nun Programme X und Y beide Abhängigkeit Z brauchen, bringen sowohl X, als auch Y Abhängigkeit Z als eigenständiges Paket unter z.B. /usr/lib/Z/ mit. Somit wird Z nur einmal installiert und nicht zweimal. Damit nicht X beider Deinstallation Y die Abhängigkeit Z "wegnimmt"(oder umgekehrt), haben beide Z als oben genannte „neue Art von Abhängigkeit“; die Paketverwaltung weigert sich nun Z zu deinstallieren, da es ja noch benötigt wird.
Damit das so funktioniert und die Paketverwaltung zwischen dem eigentlichen hauptpaket(X oder Y) und der Abhängigkeit(Z) unterscheiden kann, wird Z nicht nahtlos in X integriert, sondern als eigenständiges Debian-Paket in den Paketinhalten von X oder Y. Bei der Installation von X oder Y muss natürlich das jeweils mitgebracht Z, sofern noch nicht installiert, automatisch entpackt und mitinstalliert werden. Bei der Deinstallation natürlich auch, sofern es nicht von einem anderen Paket benötigt wird.
|
Cruiz
Anmeldungsdatum: 6. März 2014
Beiträge: 5557
Wohnort: Freiburg i. Brsg.
|
Und was soll der Vorteil sein?
|
eierl.Wollmilchsau
(Themenstarter)
Anmeldungsdatum: 24. Juli 2014
Beiträge: 144
|
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.
|
jug
Ehemalige
Anmeldungsdatum: 19. März 2007
Beiträge: 12335
Wohnort: Berlin
|
eierl.Wollmilchsau schrieb: Zunächsteinmalbräuchte es eine „neue Art von Abhängigkeiten“, diese Abhängigkeiten werden bei der Installation nicht beachtet, aber bei einer potenziellen Deinstallation der Abhängigkeits selbst, nicht des Hauptpaketes, weigert sich die Paketverwaltung die Abhängigkeit zu deinstallieren, wenn sie noch von einem anderen Paket benötigt wird.
So ist das doch im Moment auch. Also wenn du ein Paket deinstallieren willst, von dem noch andere Pakete abhängen, dann wird zumindest deutlich gewarnt, was da alles deinstalliert wird. Man muss das bestätigen, automatisch entfernt wird da nichts.
Jedes Paket bringt seine Abhängigkeiten selbst mit, aber nicht als eigenständige Kopie, a la OS X/Windows, sondern als eigenständiges Paket in den eigen Paketinhalten. Wenn nun Programme X und Y beide Abhängigkeit Z brauchen, bringen sowohl X, als auch Y Abhängigkeit Z als eigenständiges Paket unter z.B. /usr/lib/Z/ mit. Somit wird Z nur einmal installiert und nicht zweimal. Damit nicht X beider Deinstallation Y die Abhängigkeit Z "wegnimmt"(oder umgekehrt), haben beide Z als oben genannte „neue Art von Abhängigkeit“; die Paketverwaltung weigert sich nun Z zu deinstallieren, da es ja noch benötigt wird.
Also genau so, wie die Paketverwaltung jetzt schon funktioniert. Nur dass bei der Paketverwaltung die Pakete nicht „in dem Paket“ mitgeliefert werden sondern, dass im Paket halt drin steht „Ich brauche Z-0.4.2 zum funktionieren“ und die Paketverwaltung dann halt Z aus dem Repository installiert. Also nochmal die Frage, was bei deinem Vorschlag jetzt der Vorteil sein soll. Übrigens kann die Paketverwaltung in auch mehrere Versionen einer Bibliothek verwalten und parallel installiert haben. Der Entwickler einer Software muss also wirklich nur vorgeben, gegen welche Version er sein Programm entwickelt hat und den Rest macht die Paketverwaltung. ~jug
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Nur mal nebenbei, eierl.Wollmilchsau, am „Sourcecode“ Deines Beitrags (z.B. wenn man ihn zitiert) sieht man, dass Du schon sowas wie Absätze benutzen willst. Hast Du bemerkt, dass die Forensoftware daraus einen riesigen Textblock macht? Wenn Du zweimal
⏎ drückst, klappt's auch mit den Absätzen. 🤓
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53601
Wohnort: Berlin
|
eierl.Wollmilchsau schrieb: Hätte da so eine Idee:
Mach doch einfach mal Nägeln mit Köpfen! Schreibe deinen Vorschlag dorthin, wo es tatsächlich Leute gibt, die diesen umsetzen können.
Erkläre dort, warum dein Vorschlag technisch sinnvoll ist und was er konkret verbessern würde.
|
Benno-007
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
jug schrieb: eierl.Wollmilchsau schrieb: Zunächsteinmalbräuchte es eine „neue Art von Abhängigkeiten“, diese Abhängigkeiten werden bei der Installation nicht beachtet, aber bei einer potenziellen Deinstallation der Abhängigkeits selbst, nicht des Hauptpaketes, weigert sich die Paketverwaltung die Abhängigkeit zu deinstallieren, wenn sie noch von einem anderen Paket benötigt wird.
So ist das doch im Moment auch.
Genau. Und apt-mark markiert auch die Pakete X und Y als manuell installiert, Z dagegen nicht, also ist es "nur" eine Abhängigkeit. Wenn man nun X deinstalliert, bleibt Z noch erhalten. Versucht man, Z zu deinstallieren, wird gewarnt, dass X und Y deinstalliert würden. Aber es kommt ja kein normaler Mensch auf die Idee, eine Lib zu deinstallieren, sondern er deinstalliert sein installiertes X oder Y und wird nicht mit solchen Entscheidungsfragen belästigt. Sollte man nun X UND Y deinstalliert haben, bleibt Z auch noch installiert - wird aber bei Updates mit sudo apt-get dist-upgrade für die weitere, manuelle Entfernung mit autoremove vorgeschlagen, da es von keinem anderen Paket mehr benötigt wird. Will man Z behalten, kann man es z.B. nochmal zur install angeben, woraufhin es (auch, wenn es gerade kein Update davon gibt) automatisch als manuell installiert markiert wird. Dann wird es auch von autoremove in Ruhe gelassen. Grüße, Benno
|
eierl.Wollmilchsau
(Themenstarter)
Anmeldungsdatum: 24. Juli 2014
Beiträge: 144
|
Ich glaube, ihr habt das nicht ganz verstanden. Das hat mit apt-mark auto oder manual nur insofern etwas zu tun, dass die Abhängigkeiten nach der Installation dann natürlich via apt-mark auto als "Abhängigkeiten" gekennzeichnet werden müssen. Ansonsten müsste man die Abhängigkeiten immer manuell entfernen.
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. Fragt sich nur noch, wie die automatische Mitinstallation, aber nicht Deinstallation(das geschieht dann mit autoremove) der enthaltenen Pakete gelöst werden möchte.
|