@DonKult, die konkrete kleine Frage war eigentlich nur:
Sind konkrete Nachteile zu erwarten, wenn man ein apt Paketsystem dauerhaft mit zwei verschiedenen Releases fährt in unterschiedlichen Prioritäten?
Ich habe genau dies schon gemacht, wechselnd mit testing versus sid und keine nachteiligen Auswirkungen gespürt. Mit openSUSE und seinen spezial obs-Buildverzeichnissen sind verschiedene Prioritäten mein täglich Brot.
Deine verschiedenen Äusserungen zu meinem Plan animieren mich zu Konkretisierungen:
Metapaket easy-upgrade Depends: udev ( = x.y-z), kernel ( = x.y-z), …
oder wie? Wenn dem so ist, ist das schon Käse: Die einfachste Lösung wenn dann udev x.y-z+b1 rauskommt ist dann nämlich für den Paketmanager das Metapaket easy-upgrade zu entfernen und udev zu upgraden. Macht auch am meisten Sinn…
Das Metapaket ist ja gewollt, manuell (aptitude) und vom priorisierten "aptode-sideb" Release. Das udev Paket ist nicht gewollt, sondern nur automatisiert durch das Metapaket per Abhängigkeit reingezogen: Was ist das für ein Paketmanagement, dass mir ein nicht gewolltes udev auf Kosten des gewollten und höher priorisierten Metapaketes upgraded?
Kann doch nicht sein, ist das Dein apt?
Ich spiele gerade mit einem n810 herum, bei dem genau diese technik für Distroupgrades verwendet wurde. ARGH!! Kann ich da nur sagen, das hagt hinten und vorne und da liegt das Repo unter vollständiger Kontrolle von Nokia
Genau, Genießer unseres "easy" Debian sid stehen vollkommen unter der _Kontrolle_ des "aptode-sideb" Release Teams. Außer sie deinstallieren unsere Metapakete.
Unattended Upgrades ist für unstable auch eine eher schwer vorstellbare Idee… Vor allem wenn du nur bestimmte Pakete so upgraden willst.
Die bestimmten Pakete des Release Teams sollen automatisch upgegraded werden und alle sonstigen Pakete des Nutzers, wenn sich mit "apt-get dist-upgrade --simulate" kein Fehlerlevel ergibt. Bei einem Errorlevel wird der Nutzer benachrichtigt werden müssen, dass das Release Team Mist gebaut hat und nun manuell eingegriffen werden muss. Dann ist im Supportforum eine Aufgabe vorhanden!
Ich kann nur immer mein Lieblings-Squeeze Beispiel nennen: udev upgrade erfordert upgrade auf KDE4. Ein Nutzer freut sich sicher wenn das KDE3 auf KDE4 Upgrade plötzlich nach einem Reboot vollzogen ist ohne das er vorher was davon wusste.
Man kann im Supportforum solch wichtige Änderungen vorher ankündigen. Vielleicht finden wir eine Technik, die automatische dist-upgrades vorübergehend ausstellen kann:
Ein dummy Paket, was als Flag missbraucht werden kann:
Dummy-1.gruen
Dummy-2.rot
Und schlussendlich: Nur weil die Kiste bootet heißt noch lange nicht, dass deine Nutzer vor dem gröbsten beschützt sind. Vor allem weil auch nicht jeder Nutzer das selbe braucht um zu booten. Man nehme nur verschlüsselt vs. unverschlüsselte Partition. Raid vs kein, LVM vs kein, ……………
LVM Nutzer sind keine Einsteiger oder sonstwie "easy" Debian sid Kandidaten. Im Gegenteil ist LVM für mich ein Tag für ein richtiges "Frontschwein" im Release Team.
Wenns einsteigerfreundlich sein soll, dann sollte WLan noch funktionieren
So etwas muss weiterhin wie bisher "manuell" im Forum supportet werden.
AMD mal Wochenlang aus der Linux-Treiberentwicklung für ihre Grafikkarten aussteigt - Kernel einfrieren und beten
Kernel einfrieren und beten, dass nouveau und gallium bald perfekt sind. Es gibt schon erstaunliche aber seltene Teilergebnisse auf openbenchmarking.org
Bug auf i386 der auf amd64 (und allen anderen Archs) nicht Auftitt?
Ich möchte nur amd64 unterstützen! Der wichtigste Grund neben Faulheit ist, dass genau i386 von Debian Entwicklern immer seltener getestet wird. Durch das Multiarch, was Du mir so schön erklärt hattest, können 32bit Aufgaben bald perfekt gelöst werden. Für uralte Computer ist das aktuelle Debian sowieso nicht mehr geeignet. Die werden mit Puppy bestückt.
PS: Irgendwie komisch. Ich komme mir vor, als ob ich DonKult erklären müsste, wieviel sich mit seinem apt Paketsystem erreichen lässt.