[solved]D-U entfernt GNOME (in Firestarter-KDE)

[musca]

Hallo micha,

sehr schön hereingefallen, michaa7.  Tatsächlich ist auch inkscape eine Dependency des Pakets "gnome".

Oder anders formuliert, der Benutzer will bestimmt den gesamten GNOME-Desktop loswerden, wenn er gerade mal nicht inkscape aus dem Repo installieren kann. Frühere Versionen des Pakets "gnome" hatten das Browserplugin "xul-ext-adblock" als dependency und diese Abhängigkeit ist zerbrochen, als in Wheezy die Iceweasel Version 10 durch Version 17 abgelöst werden musste. Das war allerdings irgendwie unangenehm, denn da war Wheezy schon stable!

Grüße
musca

[michaa7]

Hallo micha,

sehr schön hereingefallen, michaa7.  Tatsächlich ist auch inkscape eine Dependency des Pakets "gnome".

Jain.

Zugegeben, ich hätte nicht gedacht, dass entwickler derart bescheuerte abhängigkeiten definieren. (Im grunde bestätig das nur meine abneigung gegen DEs und bestärkt mich darin weiter bei meiner xorg-fluxbox-IDGIS-DE-strategie zu bleiben.) Andererseits, um das doch auch mit ruhe zu betrachten, stellt sich doch die frage, ob autoremove anders reagiert, wenn inkscape, shotwell und was weiß ich von "automatisch" auf "manuell" installiert gesetzt würden. Wenn dann autoremove es immernoch deinstallieren will wäre das mindestens ein wishlist-bug. Ob es vielleicht sogar als höherwertiger bug zu bezeichne wäre hinge natürlich davon ab welches tatsächliche verhalten von den machern als wünschenswert erachtet wird.

Oder anders formuliert, der Benutzer will bestimmt den gesamten GNOME-Desktop loswerden, wenn er gerade mal nicht inkscape aus dem Repo installieren kann

...

Sehr schön auf den punkt gebracht.

;-)

[melmarker]

hmm - ich würd mal die Kirche im Dorf lassen - irgendwozu ist autoremove bestimmt cool zu gebrauchen - wir hatten ja auch mal die Diskussion über die Installation von Recommends, ich gebe zu ich hatte die angestoßen. Nachdem ich die Auswirkungen davon gesehen habe, war ich schlagartig von dieser Idee geheilt - obwohl es sehr interessant ist zu sehen, was debian alles so installieren würde

Es ist aber so wie mit allen Werkzeugen, nicht alles, was einem als Fehler erscheint, ist einer. Und ein Programm, was man a) nicht kennt b) eigentlich nicht vorhat, kennenzulernen) mit c) weiteren Optionen auszurüsten, die man eh nie nutzen wird, halte ich für nicht unbedingt den cleversten Weg.

Nur noch eins - klar melden sich dann auch Programme, die man kennt bei einem Autoremove. Was ist aber mit der überwiegenden Zahl von Pakten, die man nicht kennt - und die eventuell keine Dependencies sind, sonder eventuell Recommends? Die schweigen dann hübsch beim Entfernen, nehmen aber unter Umständen wichtige Funktionalität mit. Merkt man meist nicht sofort - und wenn man das dann merkt, ist es nicht mehr nachzuvollziehen, wer die geliefert hat.

Nur meine beiden Cents dazu.

[der_bud]

... Andererseits, um das doch auch mit ruhe zu betrachten, stellt sich doch die frage, ob autoremove anders reagiert, wenn inkscape, shotwell und was weiß ich von "automatisch" auf "manuell" installiert gesetzt würden....

Hi michaa7, das sollte funktionieren. Als ich mich heute mittag als hanisch seine Frage gestellt hat in das Thema "reingegoogelt" habe, fand ich zahlreiche Posts zum "why does autoremove wants to delete half of my system". In den meisten Fällen kam dann irgendwann die Antwort, soweit ich das verstanden habe, dass man den Paketen von denen man sicher ist sie behalten zu wollen, ein 'apt-get install $paketzubehalten' schickt um sie dadurch auf "manuell installiert" zu setzen.

---
Edit: musca wies mich darauf hin dass letzteres auch sinnvoller geht, "alternativ geht auch:  apt-mark manual <paket>,   es reicht, das Flag zu setzen, weil das Paket ja schon (bzw. noch) installiert ist"

[michaa7]

Danke der_bud.

So macht das autoremove natürlich mehr sinn, weil es dadurch steuerbar wird (nicht dass ich behaupten will das wäre dadurch idiotensicher, aber muscas erklärung zu metapackeges und deine nachforschungen zusammengenommen gehen doch in die richtung, dass durch einen iterativen prozess autoremove vielleicht auch in sid sinnvoller eingesetzt werden kann als bislang angenommen. Nach dem ersten aufruf und einem ergebnis wie bei Hanisch setzt man erstmal die anwendungen, die man behalten will auf "manuall" und schaut dann was der nächste durchlauf bringt. Ähnlich wie man das manchmal beim downgraden machten muß wenn pakete klemmen.

Thanks.

[piper]

We strongly recommend to not use apt-get autremove and apt-get upgrade on sidux. Both are not suited for the complex dependency and name changes in Debian sid.
apt-get clean and autoclean are completely ok and recommended.

Thank you der_bud, for the quote and post, and this is exactly what I meant about basics, and I have followed this (the quote)  before sidux, I actually think I first seen this posted in the knoppix or debian  forums first  iicrc.

I pretty much took it for granted that people knew not use autoremove in debian sid, and if they did, they were on their own.