Re: Stable Updates zu DSA 815-1 (kdebase)
Gruesse!
* 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.
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.
> > 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.
Für Neu-Installationen wird sowieso immer das aktuellste vom Server
gezogen und für die korrekte Installation per apt-get update sorgt die
Versions-Nummerierung.
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.
> > alle anderen Pakete sind ja von den Depends her nicht betroffen. Und nur
> > dieses Paket müßte upgedatet werden ohne daß ich mir eine kaputte
> > Paketverwaltung einhandele.
>
> Dafür ist die Infrastruktur nicht ausgelegt.
Das kann ich mir eher vorstellen als (s.o.) das es die Paketverwaltung
nicht könnte.
> > Angenommen ich würde mir für beide DSAs (also kdebase und der zu X) nur
> > die Pakete per Hand aktualisieren, die im Announce zum Download
> > angegeben werden. Dann habe ich doch ein genauso "sicheres" System als
> > wenn ich mit apt/aptitude/synaptics/... den ganzen anderen Rattenschwanz
> > mit aktualisiert hätte.
> >
> > Das würde aber doch heißen, daß der Update-Mechanismus über apt in
> > diesen Fällen "Mist" ist. Da er mehr Rücksicht auf namentliche
> > Gepflogenheiten nimmt statt auf sicherheitsbedingte.
>
> Nein. Apt ist hier unschuldig. Es kann ja nicht wissen welche Teile des
> Gesamtpaketes sich geändert haben.
Mein Beispiel mit kdebase oben war Mist. Ich habe mir das komplette DSA
jetzt mal durchgelesen und auch dort werden z.B. kate, etc als zu
aktualisieren angegeben. Bliebe lediglich die Frage ob kate unbedingt
neu gebaut werden mußte aufgrund eines Bugs in kdebase, aber da vertraue
ich dem SecurityTeam.
>
> 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.
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.
>
> ttyl8er, t.k.
Gruß
Gerhard
--
It's nice to be important...
but it's more important to be nice.
Reply to: