Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic: [DE] techn Machbarkeit von aptode-sideb - Bitte nicht stören  (Read 10757 times)

Offline ralul

  • User
  • Posts: 1.814
[DE] techn Machbarkeit von aptode-sideb - Bitte nicht stören
« on: 2011/07/24, 12:54:45 »
Bitte hier nicht mit reinen Gut,schlecht-find Meinungen stören!

Quote from: "devil"
Quote
Sprich, es sollte nicht für jeden bei jedem DU die Gefahr bestehen ein unbootbares System zu bekommen,
kannst du mal bitte ein expose über die machbarkeit schreiben, damit man das diskutieren kann?


1. Es sollte einen DU Modus für Einsteiger oder Benutzer, die nicht tief technisch interessiert sind, geben, der ein bootbares System weiterhin garantiert.

2. Dieser Benutzerkreis kann es verkraften Paketversionen, die veraltet sind, auch eine Woche länger zu fahren. Sie benutzen jedoch kein Debian stable oder testing, weil sie eine Verspätung aktueller Software von 5-20 Monaten nicht akzeptieren.

3. Wenn wir die zB die ubuntu "unattended Upgrades" Technik verwenden um eigene Hooks einzubauen, die ungefähr wöchentliche Updates garantieren könnten, hätte unsere Distro genau das, was viele suchen (Alleinstellungsmerkmal).

4. Metapakete können ins Leere zielen, sprich Installationen und Upgrades eine zeitlang nicht möglich sein, weil wir "Frontschweine" noch keine sauberen Versionen vorgefunden haben. Dies ist für einen Benutzerkreis im Modus "easy" aber eine zeitlang akzeptabel und entspricht vollkommen den jetzigen "Upgrade Warnings" momentan das System nicht anzufassen. Durch den Einsatz von Metapaketen braucht dieser Benutzerkreis aber das Forum "Upgrade Warnings" nicht zu lesen. Der "easy" Benutzerkreis merkt nach einer Woche nur, dass immer noch keine Pakete aktualisiert wurden (Wenn derjenige sich dafür interessierend in die "About" Infos schaut).

5. Die Schwierigkeit, der Drawback:
In einer Phase, in der DUs ausgelassen werden, harmoniert die installierte Systembasis des Benutzers nicht mehr mit den Debian sid Repos. Dies wird besonders in solchen Phasen vorkommen, in denen Debian sid strukturell stark vorbereitet wird für das nächste Release, was man bei openSUSE Milestones nennt (dies war jetzt gerade passiert mit Debian). Dadurch kann es vorkommen, dass der Benutzer neue Software eine Zeitlang nicht erfolgreich installieren kann. Wir könnten für solche Phasen erklärende Meldungen vorhalten, die erscheinen.

6. Der 5. "Drawback" Punkt ist verhinderbar durch eigene gefixte Pakete. Dies ist also auch eine Frage der Entwicklung unseres Engagements und Könnens.
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline ralul

  • User
  • Posts: 1.814
techn Machbarkeit von aptode-sideb - Bitte nicht stören
« Reply #1 on: 2011/07/24, 13:13:03 »
Die Lösung des DU Problems sehe ich als essentiell. Die Herausgabe einer Live Distibution mit eigener Artwork ohne diesen Punkt anzugehen, wäre für mich ohne tieferen Sinn.

Alle anderen Punkte sind schon jetzt sehr schnell verwirklichbar:
- für Artwork gibt es bei uns Könner
- Proprietär Hilfen wurden hier auch schon angeboten (towo, agaida)
- eine eigene Live CD haben auch schon einige von uns zusammengestellt.
- Kernel wurde schon gebacken (towo, agaida, ich mit bfs, brummer rt)
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline ralul

  • User
  • Posts: 1.814
techn Machbarkeit von aptode-sideb - Bitte nicht stören
« Reply #2 on: 2011/07/24, 13:22:55 »
Zum Aufwand für uns "Frontschweine" (agaidas Bezeichnung):

- Wir könnten mit etwas Script-hacking Aufwand eine Server Funktion basteln, die unsere eigenen privaten Booterfolge mit neuen Software Versionen sammelt.

- Wenn eine festgelegte Anzahl von Reboots einer festgelegten Anzahl von uns "Frontschweinen" stattgefunden hat, kann automatisch ein aktualisiertes Metapaket erstellt und freigegeben werden. Wenn von uns nicht einer händisch auf dem Server "stop" gesagt hat ...


Zum Sinn eines neuen Release Namens mit erhöhter Priorität:

- Ein "aptode" oder "sideb" in der Herkunftsanzeige von Paketen (unter aptitude ist dies konfigurierbar) erhöht die Transparenz unseres Tuns und des Unterschieds zu reinem Debian sid
- aptosid.com benennt seine Pakete mit "aptosid" im Versionsstring
- Grundsätzlich wäre die vorgeschlagene Technik DUs über Metapakete zu steuern auch ohne erhöhte Prioritätssetzungen (apt/preferences) und damit auch ohne einen zusätzlichen "aptode" Release Namen möglich.

Warum sollte man apt Steuerungstechniken, die alles transparenter machen können, nicht einsetzen? DonKult ist hier gefragt, ob es Nachteile eines solchen Vorgehens geben mag.
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline devil

  • Administrator
  • User
  • *****
  • Posts: 4.838
techn Machbarkeit von aptode-sideb - Bitte nicht stören
« Reply #3 on: 2011/07/24, 13:27:20 »
irgendwas davon technisch bei dir schon umgesetzt?

greetz
devil

Offline ralul

  • User
  • Posts: 1.814
techn Machbarkeit von aptode-sideb - Bitte nicht stören
« Reply #4 on: 2011/07/24, 13:35:17 »
Ich bin kein Debian Paketier Spezialist, ich sehe mich eher beim Kernel patchen. Meine Erfahrungen mit Paketabhängigkeiten in aufsteigender Schwierigkeit:
- Debian Release Wechsel sid zu testing und zurück (geht manchmal)
- Ubuntu Wechsel kubuntu-xubuntu per Metapaketen
- openSUSE Release Wechsel (zypper)
- Ubuntu Release Wechsel (aptitude)
- Gentoo mit nicht offiziellem gcc-4.6 erfordert eigenes Repo
experiencing siduction runs better than my gentoo makes me know I know nothing

DonKult

  • Guest
Re: techn Machbarkeit von aptode-sideb - Bitte nicht stören
« Reply #5 on: 2011/07/24, 15:08:49 »
Quote from: "ralul"
Warum sollte man apt Steuerungstechniken, die alles transparenter machen können, nicht einsetzen? DonKult ist hier gefragt, ob es Nachteile eines solchen Vorgehens geben mag.

Eigentlich muss ja jeder selber erstmal auf die Nase fallen und eigentlich hab ich das ja sogar schon im alten Thread erwähnt, aber weil mein Name da steht und sonst noch wer auf die Idee kommt ich hätte damit was zutun, bitte:

Wie soll das den aussehen:

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…
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… nicht wie unstable mit einem nie enden wollendem Fluss an neuen Versionen (mit neuen Bugs und Fixes, möglichst mehr letzteres als ersteres).


Unattended Upgrades ist für unstable auch eine eher schwer vorstellbare Idee… Vor allem wenn du nur bestimmte Pakete so upgraden willst. 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. Das kann man weniger drastisch auf jede größere Veränderung ausweiten. Xorg -> hal -> udev -> Xorg Konfiguration von Tastaturen und Co z.B. … oder auch nur iceweasel 8 -> 9 (vor allem weil für den ja auch ein iceweasel restart zwingend nötig ist).


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, ……………
(daher wird die Erstellung von diesen ominösen Metapaketen auch nochmal so lustig, Nokia untersützt mit n810 nur ein genau definiertes Target-Device, wie ist das hier?)

Wenns einsteigerfreundlich sein soll, dann sollte WLan noch funktionieren (viel Spaß beim auftreiben aller Hardware zum testen), der Browser natürlich auch (alle bitte, gibt ja Auswahl, da müssen die größten schon drin sein) und was macht man eigentlich wenn meinetwegen AMD mal Wochenlang aus der Linux-Treiberentwicklung für ihre Grafikkarten aussteigt - Kernel einfrieren und beten oder AMD-User im Regen stehen lassen. (AMD ist jetzt extrem, genausogut kann man irgendwas anderes nehmen: z.B. ein schwer zu findenden Bug auf i386 der auf amd64 (und allen anderen Archs) nicht Auftitt?(geschieht gerade mit APT auf sparc, hatten wir aber auch schon auf amd64 und allen anderen Architekturen… Man kann niemals jede Plattform mit allen Konfigurationen testen)



So, und mit der Abhandlung bin ich raus. Gern kann man mir spezifische Fragen stellen, ich werde das sicher beiläufig beobachten und eventuell mal meinen Senf abgeben wenns (nicht) passt, aber entgeltfreier Unternehmensberater für ein "not-yet-defined" werde ich sicher nicht, ich hab für den Job schon bei Debian "unterschrieben".

(und weil ralul mal gefragt hast: DD bin ich nicht - hab mich bisher nicht beworben - Titel ändern ja an der Arbeit nix)

Offline ralul

  • User
  • Posts: 1.814
Re: techn Machbarkeit von aptode-sideb - Bitte nicht stören
« Reply #6 on: 2011/07/24, 22:57:33 »
@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:
Quote from: "DonKult"
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?

Quote
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.

Quote
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!

Quote
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
Quote
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.

Quote
Wenns einsteigerfreundlich sein soll, dann sollte WLan noch funktionieren
So etwas muss weiterhin wie bisher "manuell" im Forum supportet werden.

Quote
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

Quote
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.
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline brummer

  • User
  • Posts: 276
    • http://guitarix.sourceforge.net/
Re: techn Machbarkeit von aptode-sideb - Bitte nicht stören
« Reply #7 on: 2011/07/25, 07:15:48 »
Quote

Ich möchte nur amd64 unterstützen!

 :evil:  :evil:  :evil:
x86 x86 x86 x86 x86 x86 x86 x86 x86 x86

DonKult

  • Guest
Re: techn Machbarkeit von aptode-sideb - Bitte nicht stören
« Reply #8 on: 2011/07/25, 09:13:43 »
Quote from: "ralul"
Sind konkrete Nachteile zu erwarten, wenn man ein apt Paketsystem dauerhaft mit zwei verschiedenen Releases fährt in unterschiedlichen Prioritäten?

Macht natürlich keine Sorgen -- viele haben die wildesten Mixe aus testing/unstable/experimental, aber ganz brav stable und stable-backports ist der selbe Fall -- allerdings muss man es dafür auch konfigurieren. UND auch wenn man mehrere Quellen hat: Eine Quelle ist die Hauptquelle, wenn man Pakete aus einer anderen haben will muss für gewöhnlich Handangelegt werden: apt-get install foo/barrelease

Das passt dir natürlich nicht ins Gehege, weil man sich dann z.B. auf testing als Hauptquelle festlegt, aber nicht "mit Metapaketen" aus unstable andere Sachen automatisch "hochziehen" kann. Genausowenig wie man Hauptquelle unstable nehmen kann und "Metapakete" aus der selben (naja, eigentlich aus einer ganz anderen Quelle) dann die Installation von anderen Versionen verhindern.
Mehrere Quellen machen von einem Automatismus her gesehen nur dann Sinn, wenn in der Hauptquelle das Paket selbst nicht vorhanden ist.


Quote from: "ralul"
Was ist das für ein Paketmanagement, dass mir ein nicht gewolltes udev auf Kosten des gewollten und höher priorisierten Metapaketes upgraded?

Ein vollkommen normales, weil dein Metapaket quasi überhaupt keine reverse Dependendencies hat während von udev Gott und die Welt abhängt. Da ist die einzig logische Entscheidung das "veraltete" Metapaket zu entfernen statt den globalen Fortschritt mit udev aufzuhalten… Man macht schließlich ein dist-upgrade… Eine Depends = x.y-z (ja mit Debian-revision z, was in Debian sehr unüblich ist - aber für deine Zwecke unabdingbar wäre) ist sehr schnell veraltet, ich kann mir kaum vorstellen, dass du ein Grundsystem (mal davon abgesehen, dass man das mal definieren müsste) zusammenstellen kannst und dieses Metapaket erstellen kannst was dann auch nur die Hälfte des Jahres überhaupt installierbar wäre……
Schon alleine weil nicht jede deiner "sicheren" Versionen  testing erreichen werden - verschwinden also mit dem erscheinen einer neuen Version direkt.

Quote from: "ralul"
Quote
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.

Wie kommst du auf die Idee? Die Festplatte verschlüssen kann heute jeder, viele Installer bieten dazu eine mehr oder minder einfach Option an. Dafür muss man kein Experte sein. Das machen selbst Leute auf Windows, warum muss ich als Umsteiger direkt in die Expertenschiene wechseln? Und für Raids und LVM sicher auch nicht, man wird ja auch nicht zum Experte von Debian dadurch. Die ganze Hardwareschiene der Argumentation hast du ja freundlichst ignoriert: Die kommt ja noch oben darauf…

Quote from: "ralul"
Quote
Bug auf i386 der auf amd64 (und allen anderen Archs) nicht Auftitt?
Ich möchte nur amd64 unterstützen!

Ne, so wie du dich anhörst möchtest du nur die Architekturen: raluls-laptop und raluls-desktoppc untersützten. Dann könnte(!) das sogar klappen, meine Behauptung ist nur, dass das nicht hoch skaliert auf komplett "amd64" (mal von abgesehen, dass das die Beschränkung zu diesem Zeitpunkt auch ein wenig Käse ist, aber egal).

Quote from: "ralul"
PS: Irgendwie komisch. Ich komme mir vor, als ob ich DonKult erklären müsste, wieviel sich mit seinem apt Paketsystem erreichen lässt.

P.S. Es ist nicht "mir", damit fangen wir mal gar nicht erst an.
Doch bevor man mir Lehrstunden über das Paketmanagementsystem erteilt, sollte man besser genau wissen was man tut, sonst kommt nämlich jemand und stellt unangenehme Fragen und erbittet eine Implementierung - den am Ende ist die Realisierung das entscheidende Kriterium, nicht irgendein neunmalkluger APT-Bastler, den der kann sich irren, die Realität irrt sich aber nie.

Offline ralul

  • User
  • Posts: 1.814
Re: techn Machbarkeit von aptode-sideb - Bitte nicht stören
« Reply #9 on: 2011/07/25, 10:26:34 »
Quote from: "brummer"
Quote

Ich möchte nur amd64 unterstützen!

 :evil:  :evil:  :evil:
x86 x86 x86 x86 x86 x86 x86 x86 x86 x86

1. das ist meine erste Vormeinung
2. amd64 Beschränkung wäre nur für die Target Audience Debian sid Einsteiger und "easy" Genießer.

Jedenfalls werde ich mit amd64 anfangen
Wenn x86 "Frontschweine" dazu kommen, könnten wir da auch noch landen ...
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline cryptosteve

  • User
  • Posts: 675
Re: techn Machbarkeit von aptode-sideb - Bitte nicht stören
« Reply #10 on: 2011/07/25, 10:38:14 »
Guten Morgen,
ich weiß nicht, ob ich jetzt zu pessimistisch bin, oder einfach nur Realist, aber ...

Quote from: "ralul"
Die Lösung des DU Problems sehe ich als essentiell.


das dist-upgrade-Problem wird sich innerhalb von Debian sid nicht lösen lassen. Debian sid ist nunmal ein sich schnell bewegendes Ziel ("heavy moving target"), das sich nicht nur in Art der Pakete, sondern jeweils auch in Architektur, Branch und Alter. Dabei ist es schlussendlich so vielfältig, dass unter Beibehaltung von apt kein Mechanismus dieser Welt die dafür notwendigen Vorgänge in Stein meißeln könnte.

"easy" und "Debian sid" passen nicht zusammen, das kann nicht funktionieren. Wenn es hoch kommt, kann man einige wenige systemimmanente Programme kurzfristig vorm Upgrade bewahren. Das wars dann aber auch schon.

ralul, Deine Umsetzungsvorschläge können meines Erachtens nur zwei Effekte haben:

a) es funktioniert nicht, oder
b) es ist am Ende kein Debian sid mehr.

Ein solches Setup wäre einfach viel zu steif, um auf die Vielzahl der Installationen passend reagieren zu können. Genauso, wie die des Nächstens diskutierte Lösung, (halb-)automatisierte Rollbacks des Systems vor einem fehlerhaften DU zu machen.

Ich kürze das nochmal ab:

Entweder, man nimmt die Eigenheiten von apt unter Debian sid in Kauf, oder sid ist die falsche Ausgangsbasis, bzw. Debian die grundsätzlich falsche Distribution für ein solches Vorhaben.
- born to create drama -
CS Virtual Travel Bug: VF6G5D

se7en11

  • Guest
Re: techn Machbarkeit von aptode-sideb - Bitte nicht stören
« Reply #11 on: 2011/07/25, 11:27:42 »
+1
Das hört sich für mich "ungebildeten" nach einer menge Arbeit und potentiellen Fehlerquellen an. Man sollte doch eigentlich versuchen User zum mitdenken zu erziehen.
debian/sid ist eben unstable, ich benutze seit Jahren nichts anderes und hatte nicht ein mal ein Problem.
Ich finde jeder der sid nutzt sollte lesen können und auch mal ein paar std warten können wenn das halbe System deinstalliert werden sollte. Man kann versuchen Hilfestellungen zu geben sollte aber nicht versuchen ein System zu schaffen das einem das denken abnimmt.

Offline ralul

  • User
  • Posts: 1.814
Re: techn Machbarkeit von aptode-sideb - Bitte nicht stören
« Reply #12 on: 2011/07/25, 11:47:33 »
Ich merke schon, auch an der Frage von devil, ich muss es erstmal selbst mindestens beispielhaft implementieren, um Anhänger für die Idee zu finden. Wie es immer bei openSource ist, dass man nur interessieren kann, wenn man konkret etwas vorweist, und nicht nur drüber redet - DoKratie.
Quote from: "DonKult"
Eine Quelle ist die Hauptquelle, wenn man Pakete aus einer anderen haben will muss für gewöhnlich Handangelegt werden: apt-get install foo/barrelease

Das passt dir natürlich nicht ins Gehege, weil man sich dann z.B. auf testing als Hauptquelle festlegt, aber nicht "mit Metapaketen" aus unstable andere Sachen automatisch "hochziehen" kann.
Ich bezieh mich nicht auf testing, aber vom Prinzip dachte ich es sollte so funktionieren:

/etc/apt/sources.list
Code: [Select]
deb  http://ftp.de.debian.org/debian/ unstable main contrib non-free
deb http://ftp.aptode.org/debian/ aptode main fix easy
etc/apt/preferences
Code: [Select]
Package: *
Pin: release a=unstable
Pin-Priority: 501
Package: *
Pin: release a=aptode
Pin-Priority: 502
Die Metapakete für "easy" Debian Benutzer werden aus dem Verzeichnis easy gezogen, und sind durch die erhöhte Priorität (502) geschützt? Ginge mein Plan besser mit beiden Prioritäten über tausend?
Quote
Quote from: "ralul"
Was ist das für ein Paketmanagement...
Ein vollkommen normales, weil dein Metapaket quasi überhaupt keine reverse Dependendencies hat während von udev Gott und die Welt abhängt. Da ist die einzig logische Entscheidung das "veraltete" Metapaket zu entfernen statt den globalen Fortschritt mit udev aufzuhalten…
Dazu will ich die erhöhte Priorität des aptode-sideb Releases benutzen, reicht nicht?
So kenne ich es von openSUSE und Gentoo.
Quote
ich kann mir kaum vorstellen, dass du ein Grundsystem (mal davon abgesehen, dass man das mal definieren müsste) zusammenstellen kannst und dieses Metapaket erstellen kannst was dann auch nur die Hälfte des Jahres überhaupt installierbar wäre……
Ja, die durchgehende Installierbarkeit wäre ein Argument die Pakete selbst zu hosten, nicht nur Metapakete. Allerdings geht es bei meinem Projekt nicht um Installierbarkeit, sondern um die nachfolgende "easy" Pflege. Ich kann mir einen Button vorstellen zur Umstellung eines Systems nach der eigentlichen Installation:
"easy" einrichten.
Quote
Ne, so wie du dich anhörst möchtest du nur die Architekturen: raluls-laptop und raluls-desktoppc untersützten.
Sehr beschränkt anfangen gehört zum Plan.
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline brummer

  • User
  • Posts: 276
    • http://guitarix.sourceforge.net/
Re: techn Machbarkeit von aptode-sideb - Bitte nicht stören
« Reply #13 on: 2011/07/25, 11:53:21 »
schön wäre z.b. wen der Installer für /home eine eigene Partition anlegen würde, bzw. eine bestehende /home Partition einbinden könnte. Damit wäre ein upgrade über eine neu Installation machbar, also upgrade nur wenn eine neue CD erscheint, das wäre dann die 85%ige Sicherheit (Abteilung sorglos)
Die Arbeit für das (sorglos) Team wäre dabei sicherzustellen, das bestimmte configs, die nicht mehr funktionieren oder obsolent sind, auf die neuen Anforderungen transferiert werden, oder eben gelöscht.

Ich denke das ist eher machbar als (sorglos) zu jeder Zeit zu gewährleisten.

Offline ralul

  • User
  • Posts: 1.814
Re: techn Machbarkeit von aptode-sideb - Bitte nicht stören
« Reply #14 on: 2011/07/25, 11:58:07 »
@Steve,
@Se7en11
eure Beiträge sind Meinungsäußerung. Ihr wiederholt das allgemein übliche Urteil über Debian sid, dass es nicht geht. Dieses Urteil kenne ich, also hier:

Bitte nicht stören
experiencing siduction runs better than my gentoo makes me know I know nothing