Moinmoin, On Tue, Sep 20, 2005 at 01:13:40AM +0200, Gerhard Brauer wrote: > * Thomas Kosch <t.kosch@schuckeduster.org> schrieb am [19.09.05 20:30]: > > On Day 43 of Bureaucracy 3171, Gerhard Brauer wrote: > > > > > Ja, aber beim Bauen wird doch in einzelne Pakete (xterm,xfonts,...) > > > aufgesplittet. Warum stellt man jetzt nicht nur _das_ Paket nach > > > updates/stable was auch wirklich den Fix enthält? > > > > Weil das in der Paketverwaltung nicht vorgesehen ist. > > Hm, das ist mir irgendwie nicht nachvollziehbar. Wenn der build process > meinetwegen unbedingt alle .debs mit einer höheren Minor-Nummer bauen > muß, ist das ok. Jetzt könnte aber doch irgendjemand des SEC-Teams > eingreifen und nur das/die Pakete aus dem build auch auf den SEC-Server > laden, die wirklich verändert wurden. So ungern man es als Mensch eventuell auch hören mag, aber eine derartige manuelle Intervention würde sich als ausgesprochen fehlerträchtig erweisen. Es ist keineswegs so, daß auf gar keinen Fall ein anderes Prozedere _möglich_ wäre, es ist vielmehr das aktuelle Vorgehen sehr gut kalkulier- und überschaubar. Eine geringere Komplexität des Vorgangs wird in diesem Falle erkauft mit einem erhöhten Rechen- und Bandbreitenaufwand. > Aber wenn ich mir meinen Absatz oben jetzt nochmal durchlese klingt das > irgendwie reichlich naiv ;-) Die Wirklichkeit, die xfree und kde beim > Bauen wahrscheinlich erfordern, auch aufgrund der anderen Plattformen, > dürften anders sein als ich es "halt gerne hätte". > > Trotzdem hat das Ganze, wahrscheinlich halt auch aufgrund der > "gewachsenen Strukturen" für mich so etwas von: Ihr Rücklicht ist > kaputt? Da müssen wir ihr Auto auswechseln. Ja, der Gedanke ist nachvollziehbar. Und die Parallele in gewissem Maße durchaus zutreffend: Viele Bauteile werden heutzutage nicht mehr separat oder manuell repariert / ausgebessert, sondern stattdessen lieber in toto ersetzt, da der Hersteller glaubt, nur so eine kontrollierte Produktqualität garantieren zu können. (Sicherlich spielt auch oft die Kundenschröpfung und damit ein kommerzielles Interesse eine Rolle, aber das lasse ich bei Debian mal außen vor...) > > > Angenommen, der Fix würde später nach dem Bauen definitiv nur eine > > > Änderung im xlibs-Paket bewirken. Dann müßte doch nur dieses Paket in > > > der Packages von update/stable mit einer neuen Minor-Nummer erscheinen - > > > > So und jetzt denke das mal bis zu Ende durch. Für solche Monsterpakete > > wie Xfree/Xorg oder KDE. Und jetzt überlege mal was passiert wenn du das > > 2 Jahre lang machst. Dann hast du ein Xfree mit 15 unterschidlichen > > Versionen (von der Nummerierung her). Das willst du nicht wirklich. > > Also damit könnte ich leben. Für mich ist lediglich wichtig die > Konsistenz der Pakete von sagen wir: > xfree -> (4.)3.0 > kde -> (4.)3.3.2 > damit ich sehe, von welchem Entwickler-Zweig meine Version abstammt. Ob > kdebase jetzt 4:3.3.2-1sarge1 oder 4:3.3.2-1sarge14 ist ist mir egal > solange die Meta-Pakete und die Depends der Pakete unter sich (>= > 4:3.3.2-1) konsistent sind. Auch hier stellt sich die Frage, inwieweit dies nach einer solchen Abfolge von Aktualisierungen garantiert werden kann. Es könnten sich auf irgendwelchen verworrenen Pfaden Fehler eingeschlichen haben, die niemand hat vorhersehen können oder wollen. Bereits jetzt gibt es bedauerlicherweise schon unangenehm viele Fehler im Aktualisierungsprozess für Stable, die zumeist auf eine Nachlässigkeit eines Entwicklers zurückzuführen sind... :( > Und auch die changelogs würden für mich nachvollziehbarer sein, da, sagen > wir der X bug, wirklich in xlibs-x.y.z-12 gefixt wurde. Und eben nicht > in den xfonts-Paketen da er dort ja garnicht auftrat. Deswegen könnten > die ruhig bei xfonts-x.y.z-11 bleiben. Im gegebenen Falle sind Deine Bedenken ausgesprochen zutreffend. Es sollte jedoch nach Möglichkeit eine Einzelfallunterscheidung unterbleiben und lieber ein festes, kalkulierbares und überschaubares Regelwerk verfolgt werden, auf daß eine gewisse innere Konsistenz so gut als irgend möglich garantiert werden kann. > > Der in meinen Augen einzig sinnvolle Weg das zu lösen, ist der, den z.B > > SuSE geht. Die erstellen keine komletten Binär-Pakete sondern > > patch-rpms. Die Enhalten nur die Teile, die sich geändert haben (und > > zwar auf Dateiebene und nicht auf Paketebene) und setzen dann die > > Versionierung beim Einspielen für das Gesamtpaket entsprechend. > > > > Aber das läßt weder dpkg noch die Infrastruktur zu. > > Hm, die Infrastruktur mag sein. > Aber warum eigentlich nicht dpkg/apt? Gerade dieses Paketsystem sollte > das doch prima können. Nehmen wir mal Alexanders Beispiel der > fehlerhaften man page in xterm. > > Wenn ich jetzt ein .deb nur mit der geänderten man page habe dann müßte > ich dieses Paket doch mit dpkg/apt einspielen können und es würde aus > dem Content nur diese man page auf meinem System aktualisiert werden. > Voraussetzung eines solches Patch-debs ist natürlich, das die Liste der > bereitgestellten Files etc. auch die des Ursprungs-Paketes enthalten > damit wieder sauber deinstalliert werden kann. Gleiches für Prüfsummen > etc. > > Das einzig komplizierte wäre IMHO doch nur wenn mehrere Fixes für ein > Paket auflaufen. Da müßte der aktuellste halt auch immer den Content der > vorhergehenden beinhalten. Beim xterm man page Beispiel zu bleiben, halt > 2 oder 3 pages. Und das solange, bis für das aktuelle Debian Release ein > neuer ReleaseCandidat gebaut wird. Dann kann man auf den Update-Servern > wieder bei Null anfangen. > > Also ich als Laie kann da beim Paketsystem nicht das Hinderniss > erblicken. Es gab bereits eine Reihe von Vorschlägen, wie die entsprechenden Werkzeuge von Debian angepasst werden könnten, um eine geringere Bandbreitennutzung zu ermöglichen. Allen diesen Vorschlägen ist gemein, daß für ein Erlangen dieses Vorteils ein gewisser Preis zu zahlen ist. Sei es die oben erwähnte erhöhte Komplexität und damit Fehleranfälligkeit, sei es ganz profan eine dann notwendige höhere Rechenleistung der betroffenen Server. Zu jedem dieser Vorschläge müssen Vor- wie auch Nachteile gegeneinander abgewogen werden, und das aktuelle Ergebnis dieser Diskussionen erleidest Du gerade. Je nachdem, wie sich die einzelnen Faktoren (Bandbreitenverfügbarkeit und -kosten, Rechenkapazität und -kosten der Server, Struktur der Nutzerbasis, ...) im Laufe der Zeit ändern, werden einige dieser Vorschläge neu überdacht werden müssen, und ich bin durchaus zuversichtlich, daß eben dies geschehen wird. (Ein Beispiel zu einem Teilbereich: <http://lists.debian.org/debian-devel/2005/09/msg00494.html>) > Ach ja, noch was allgemeines zu meinem Thread: Am Anfang war ich > ziemlich sauer weil es für mich den Anschein hatte das einfach deswegen > Updates kamen weil irgendjemand den Einfall hatte Pakete mit sarge1 > enden lassen zu müssen "weil es Mode ist". Diesen Gedanken hat die > Diskussion bei mir mittlerweile beseitigt. :) > Aber zufrieden bin ich mit der Bild, daß sich mir heute bot, nicht. Das ist nachvollziehbar. Im aktuellen Szenario haben die Dial-Up-Benutzer ein ganz schönes Kreuz zu tragen. Nur leider ist eine Verbesserung ihrer Situation mit einer Vielzahl von notwendigen Erwägungen verknüpft... Viele Grüße, Flo
Attachment:
signature.asc
Description: Digital signature