Hallo Hanisch,
ich will den Gedanken von piper mal ganz sachlich und ausführlich fomulieren.
Du hast vermutlich mal das Metapaket "gnome" in ein siduction-firestarter-KDE installiert.
Kurz danach zerbrach eine der zahlreichen "Dependencies" und als Folge wurde das Paket "gnome" bei einem D-U entfernt. Dabei bleiben die Dependencies markiert als "automatisch" installiert im System zurück. Ein "apt-get autoremove" entfernt alle automatisch installierten Pakete, die nicht mehr für die verbliebenen manuell installierten Pakete benötigt werden.
Aus diesem Grund vermeidet siduction solche fetten Metapakete (vgl. "bloatware") , wo es irgend geht. Das stabilisiert die Paketauswahl, aber der Benutzer muss sich dann - nach eigenem Wunsch - darum kümmern, dem Metapaket neu hinzugefügte Dependencies manuell zu installieren. (An dieser Stelle kommt auch unser junges, noch in Entwicklung befindliches Werkzeug "addpkg" ins Spiel. Es installiert ganze Paketgruppen, aber verzichtet auf die Hilfe eines Metapakets.)
Du siehst also, dass ein einfaches "apt-get install gnome" den allgemeinen Richtlinien von siduction diametral entgegnet und zu schwer wartbaren Systemen führt. Es ist nicht immer leicht, die daraus folgenden Diskussionen sachlich zu gestalten, speziell wenn die Kritik persönlich genommen wird. Nicht nur Entwickler, sondern auch Benutzer hören es nicht gern, wenn pauschal verlangt wird "man solle sich mehr bemühen" (oder "Erfahrung sammeln", wie piper vorschlägt, denn Ubuntu hat genau dafür eine tolle Ausstattung mit deutsch-sprachiger Dokumentation).
Grüße
musca
[ Exkurs: Siduction verwendet aber durchaus Metapakete, z.B. linux-headers-siduction-amd64.
Beim unserem Headers-Metapaket kommt es z.B. bei Unterschieden zwischen den Architekturen in Multiarch-Systemen oft zu Konflikten mit dem gcc-Compiler, die bei unachtsamer Bedienung zur Entfernung des Header-Metapakets führen. Beim D-U läuft dann das Kompilieren des proprietären Grafiktreibers auf einen Fehler. Trotzdem dieser Konflikte halten wir das Metapaket hier für vorteilhaft, da es den Benutzern das regelmäßige Updaten unseres Kernels vereinfacht. Für Multiarch gilt: Bei Konflikten nicht dist-upgraden, sondern etwa sechs bis zwölf Stunden warten. ]