On Sat, Dec 09, 2006 at 03:21:48PM +0100, Iñigo Tejedor Arrondo wrote: > El sáb, 09-12-2006 a las 14:59 +0100, mariodebian escribió: > > > Sigo a menudo los planet de ubuntu, debian y gnome y si gnome 2.16 no ha > > entrado ni siquiera en sid es algo más que por capricho. > > > > Jordi Mallach [1] dijo hace tiempo que la transición a gtk-2.10 es > > bastante catastrófica sobre todo por el cambio de ABI en muchas > > librerías, fallos en el selector de archivos u otros que han hecho que > > en 15 días se publiquen hasta 4 versiones. [2] > > > > No se si has visto la infraestructura que se usa en debian para compilar > > los kernels, yo sí, un poco por encima, y lo tienen bastante > > automatizado con muchos scripts en python.... > > No se como lo tiene debian, yo tengo un script que me descarga, parchea, > compila y empaqueta el kernel y los drivers externos, y no soy ningún > guru del sh :) Pero tú estás instalando el kernel tal cual viene de kernel.org. El kernel de Debian incluye bastantes parches, que hay que revisar que aún aplican entre versiones, etc. > Lo del tema de gnome, entiendo que no es "tontería" dar ese paso. Pero > entiendo que si se deverían poner los esfuerzos en ese tema, antes que > en subir el kernel una bugversión más, no se ganan apenas drivers, y se > ganan futuras actualizaciones por código poco depurado. Se gana, entre otras cosas, soporte para dispositivos ATAPI (lectores de cd, por ejemplo) vía SATA. Lo cual es indispensable para instalar en muchas máquinas modernas. 2.6.18 tiene *bastante* tiempo en unstable, donde se le ha venido probando para lograr que sea digno de pasar a testing. No por capricho de alguien, sino por necesidad del instalador. > Gnome 2.16 > imagino que será bastante más estable que lo que era hace dos meses y... > ¿no se supone que ubuntu "devuelve" su trabajo a la comunidad debian? > entonces meter gnome 2.16 no debería costar tanto, como hacerlo desde > cero sin alguien que abra el paso... ¿o no les interesa? Las bibliotecas de GNOME son requeridas por *muchos* paquetes. Integrar 2.16 significa que hay que recompilar todos esos paquetes, y los que dependen de ellos, etc. Eso a su vez impide durante mucho tiempo migraciones de sid a etch. Hacerlo a estas alturas del _release,_ cuando lo que queremos es acabar con los bugs RC en etch, sólo causa retrasos. Además, no se trata sólo del cambio de versión 'upstream'. El empaquetamiento tiene muchos cambios, por ejemplo para evitar la generación de dependencias inecesarias en otros paquetes.[1] > En fin, quizás son imaginaciones mias. No se exactamente quien decide > cuando un paquete pasa a sid, pero si no, nunca se arreglarán los bugs, > porque lo probará la mitad de gente. Lo decide el mantenedor de ese paquete. En este caso, el equipo de gnome en Debian. > Con Jordi ya crucé dos correos hace un par de meses, mi única prueba fue > empaquetar gdm 2.16, en 20 minutos (coger el tar.gz oficial, aplicar el > dsc de gnome 2.14 cambiando dos pijadas y empaquetado y funcional a la > primera)... pena que luego otras cosas (remuneradas) me han quitado > mucho tiempo y no he podido ayudar tanto como quería. Cambiar las *aplicaciones* no es problema. El problema son las bibliotecas subyacentes. [1] Caso de ejemplo. sawfish (que ni siquiera es parte de gnome) depende de Depends: libatk1.0-0 (>= 1.12.2), libaudiofile0 (>= 0.2.3-4), libc6 (>= 2.3.6-6), libcairo2 (>= 1.2.4), libesd0 (>= 0.2.35) | libesd-alsa0 (>= 0.2.35), libfontconfig1 (>= 2.4.0), libglib2.0-0 (>= 2.12.0), libgmp3c2, libgtk2.0-0 (>= 2.8.0), libice6 (>= 1:1.0.0), libpango1.0-0 (>= 1.14.5), librep9 (>= 0.17-11), libsm6, libx11-6, libxcursor1 (>> 1.1.2), libxext6, libxfixes3 (>= 1:4.0.1), libxft2 (>> 2.1.1), libxi6, libxinerama1, libxrandr2, libxrender1, rep-gtk (>= 0.18-9), gnome-terminal | x-terminal-emulator, sawfish-data (= 1:1.3+cvs20061004-1) Pero en realidad, no usa nada de libxrandr2, libxfixes3, libxrender1, libaudiofile0, libgmp3c2, libxi6, libxcursor1, libcairo2, libatk1.0-0, libfontconfig1 Esas dependencias entran (erroneamente) debido a que libgtk2.0-dev las inserta. Si se corrige ese problema en libgtk2.0-dev sawfish dejará de depender de esos paquetes, así que futuras transiciones en ellos ya no le afectarán. Pero para eso se necesita actualizar libgtk2.0-dev *y recompilar* todos los paquetes que dependen de él. Ninguno de esos paquetes, y ninguno de los que de ellos dependen, podría migrar a etch durante días, atorando decenas de correcciones a bugs RC, retrasando *aun más* la liberación.
Attachment:
signature.asc
Description: Digital signature