# [debate]Gentoo con el culo al aire por la libexpat (cerrado)

## sefirotsama

El otro dia estaba yo tan contento con mis nuevas kdelibs 3.5.7 y mi nuevo kde con un aspecto mejorado... Y tras actualizar el sistema me dispuse a borrar algunas aplicaciones que no queria/necesitaba, entre otros juegos de kde (Ktuberling, y similares)... El caso es que al acabar a la desinstalación veo que....

Determinadas aplicaciones no se abren... ni amarok ni konqueror ni ninguna konsole qu eno estubiera abierta antes ni tan solo podia ejecutar una nueva sesión ni lanzar kdm...

Pensé en hacer un revdep-rebuild y me saca una lista del toooooooooooooodo larga con 170 paquetes

Despues de casi 20 minutos para detectar todos los enlaces rotos y que es lo que se necesita reemerger comienza el proceso... y TODAS las compilaciones fallan con un error en el ebuild igual... (luego lo posteo). EL caso es que hasta fluxbox debe ser reinstalado...

Reinicio y las X directamente no arrancan, y debo trabajar en consola donde por sorpesa veo que hay paquetes requeridos que no tengo... Además intenta bajarme a la versión 3.5.5 de algunos paquetes de kde y dependencias, cosa que no quiero. ME he asegurado de tener bien el packages.mask y no tengo el kde-meta. ¿Porqué me pasa esto?

El caso, necesito usar mi kubuntu dos:

[code]portatil y no tengo internet en casa...

Así revdep-rebuild como gentoo me ha dejado con el culo en el aire...

Y he tenido que sacrificar una partición menor donde instalar una kubuntu* para hacer chroot mientra puedo usar "algo" mi ordenador.

Voy a ser un pecador kubuntero hasta que consiga restaurar mi sistema... Ven como de vez en cuando estari bien un "portage" con opción binaria???

Error al hacer revdep-rebuild (es informativo pero luego falla):

[code]

!!! Multiple versions within a single package slot have been

!!! pulled into the dependency graph:

('ebuild', '/', 'kde-base/libkonq-3.5.5', 'merge') pulled in by

  ('ebuild', '/', 'kde-base/kdepasswd-3.5.5', 'merge')

('ebuild', '/', 'kde-base/libkonq-3.5.7', 'merge') (no parents)

It may be possible to solve this problem by using package.mask to

prevent one of those packages from being selected. However, it is also

possible that conflicting dependencies exist such that they are

impossible to satisfy simultaneously. If such a conflict exists in the

dependencies of two different packages, then those packages can not be

installed simultaneously.

[/code]

Error multiple de compilación, en este caso kdm. Me tiene desesperado:

[code]

 * ERROR: kde-base/kdm-3.5.7 failed.

 * Call stack:

 *   ebuild.sh, line 1654:   Called dyn_compile

 *   ebuild.sh, line 990:   Called qa_call 'src_compile'

 *   ebuild.sh, line 44:   Called src_compile

 *   kdm-3.5.7.ebuild, line 41:   Called kde-meta_src_compile 'myconf' 'configure'

 *   kde-meta.eclass, line 380:   Called kde_src_compile 'myconf' 'configure'

 *   kde.eclass, line 322:   Called econf '--with-x-binaries-dir=/usr/bin' '--with-pam' '--without-java' '--with-x' '--enable-mitshm' '--without-xinerama' '--with-qt-dir=/usr/qt/3' '--enable-mt' '--with-qt-libraries=/usr/qt/3/lib64' '--disable-dependency-tracking' '--disable-debug' '--without-debug' '--disable-final' '--with-arts' '--prefix=/usr/kde/3.5' '--mandir=/usr/kde/3.5/share/man' '--infodir=/usr/kde/3.5/share/info' '--datadir=/usr/kde/3.5/share' '--sysconfdir=/usr/kde/3.5/etc' '--enable-libsuffix=64'

 *   ebuild.sh, line 591:   Called die

 *

 * econf failed

 * If you need support, post the topmost build error, and the call stack if relevant.

 * A complete build log is located at '/var/tmp/portage/kde-base/kdm-3.5.7/temp/build.log'.

 *

[/code]

Las apps que debo reemerger (creo que son más):

[code]

USE="-audacious" emerge -fv  =sys-devel/gettext-0.16.1 =app-emulation/emul-linux-x86-gtklibs-10.0-r1 =dev-libs/apr-util-1.2.8 =media-libs/mesa-6.5.2-r1 =dev-util/subversion-1.3.2-r4 =sys-devel/gdb-6.6-r2 =dev-libs/apr-util-0.9.12-r1 =www-servers/apache-2.0.58-r2 =media-libs/fontconfig-2.4.2 =app-text/poppler-0.5.4-r1 =media-gfx/graphviz-2.12 =media-gfx/imagemagick-6.3.4-r1 =x11-libs/pango-1.16.4 =x11-libs/gtk+-2.10.13 =gnome-extra/gtkhtml-2.6.3 =www-client/mozilla-firefox-2.0.0.6 =gnome-base/gnome-keyring-0.6.0 =media-libs/raptor-1.4.12 =dev-libs/rasqal-0.9.10 =dev-libs/redland-1.0.4 =gnome-base/librsvg-2.16.1-r2 =kde-base/kdelibs-3.5.7-r2 =kde-base/libkdegames-3.5.7 =kde-base/kwin-3.5.7 =kde-base/libkonq-3.5.7 =kde-base/libkcddb-3.5.7 =kde-base/kdialog-3.5.5 =kde-base/kdesu-3.5.7 =kde-base/libkmime-3.5.7 =kde-base/libkholidays-3.5.7 =kde-base/kscreensaver-3.5.7 =kde-base/khotkeys-3.5.7 =kde-base/kcminit-3.5.6 =kde-base/ksplashml-3.5.7 =kde-base/kode-3.5.6 =kde-base/kmailcvt-3.5.5 =kde-base/libksieve-3.5.7 =kde-base/libkpgp-3.5.4 =dev-util/kdevelop-3.4.1 =kde-base/kget-3.5.7 =kde-base/kreadconfig-3.5.6 =kde-base/kmenuedit-3.5.7 =kde-base/cervisia-3.5.7 =kde-base/ksmserver-3.5.7 =kde-base/kdeadmin-kfile-plugins-3.5.7 =kde-base/kimagemapeditor-3.5.7 =kde-base/kmid-3.5.7 =kde-base/kdeartwork-styles-3.5.7 =kde-base/kuser-3.5.7 =kde-base/kcron-3.5.7 =kde-base/eyesapplet-3.5.7 =kde-base/kodo-3.5.7 =kde-base/kteatime-3.5.7 =kde-base/kgpg-3.5.7 =kde-base/drkonqi-3.5.7 =kde-base/nsplugins-3.5.7 =kde-base/quanta-3.5.7 =kde-base/amor-3.5.7 =kde-base/klinkstatus-3.5.7 =kde-base/secpolicy-3.5.6 =kde-base/kwalletmanager-3.5.7 =kde-base/ksim-3.5.7 =kde-base/lilo-config-3.5.7 =kde-base/kcalc-3.5.7 =kde-base/kuickshow-3.5.7 =kde-base/kmilo-3.5.7 =kde-base/kedit-3.5.7 =kde-base/kjots-3.5.7 =kde-base/kcharselect-3.5.7 =kde-base/khexedit-3.5.7 =kde-base/ktimer-3.5.7 =kde-base/ark-3.5.7 =kde-base/kdf-3.5.7 =kde-base/kmoon-3.5.7 =kde-base/kommander-3.5.7 =kde-base/kfilereplace-3.5.7 =kde-base/ksnapshot-3.5.7 =kde-base/fifteenapplet-3.5.7 =kde-base/ktux-3.5.7 =kde-base/kweather-3.5.7 =kde-base/juk-3.5.7 =kde-base/kdemultimedia-kfile-plugins-3.5.7 =kde-base/kfloppy-3.5.7 =kde-base/kview-3.5.7 =kde-base/kwifimanager-3.5.7 =kde-base/superkaramba-3.5.7 =kde-base/kregexpeditor-3.5.7 =kde-base/kxsldbg-3.5.7 =kde-base/kolourpaint-3.5.7 =kde-base/kompare-3.5.7 =kde-base/klaptopdaemon-3.5.7 =kde-base/kpersonalizer-3.5.7 =x11-themes/fahrenheit-0.1 =x11-themes/activeheart-1.2.1 =x11-themes/qtcurve-0.48.2 =x11-themes/klearlook-0.9.9.2 =x11-themes/kwin-neos-0.2b =x11-themes/tiblit-2.0_beta =kde-misc/ksmoothdock-4.5 =app-mobilephone/kmobiletools-0.4.3.3 =kde-base/libkcal-3.5.7-r1 =kde-base/certmanager-3.5.7-r1 =kde-base/kdeartwork-kscreensaver-3.5.7 =kde-base/kfind-3.5.7 =kde-base/kicker-3.5.7 =kde-base/kdepim-kioslaves-3.5.7-r1 =kde-base/kdemultimedia-kioslaves-3.5.7 =x11-wm/aquamarine-0.2.1 =kde-base/kbounce-3.5.7 =kde-base/atlantik-3.5.7 =kde-base/kscd-3.5.7 =kde-base/kpat-3.5.7 =kde-base/ksirtet-3.5.7 =kde-base/klines-3.5.7 =kde-base/ksnake-3.5.7 =kde-base/kshisen-3.5.7 =kde-base/ksame-3.5.7 =kde-base/kgoldrunner-3.5.7 =kde-base/kblackbox-3.5.7 =kde-base/kmines-3.5.7 =kde-base/ksokoban-3.5.7 =kde-base/kasteroids-3.5.7 =kde-base/kfouleggs-3.5.7 =kde-base/kwin4-3.5.7 =kde-base/kolf-3.5.7 =kde-base/ktron-3.5.7 =kde-base/kmahjongg-3.5.7 =kde-base/konquest-3.5.7 =kde-base/kjumpingcube-3.5.7 =kde-base/ksmiletris-3.5.7 =kde-base/kreversi-3.5.7 =kde-base/klickety-3.5.7 =kde-base/kspaceduel-3.5.7 =kde-base/katomic-3.5.7 =kde-base/kdeartwork-kwin-styles-3.5.7 =kde-base/kbackgammon-3.5.7 =kde-base/kenolaba-3.5.7 =kde-base/kbattleship-3.5.7 =x11-themes/alloy-0.5.3 =x11-themes/crystal-1.0.2 =x11-themes/activeheart-kwin-1.1 =x11-themes/comix-1.3.8 =x11-themes/domino-0.4 =x11-themes/qinx-1.4 =x11-themes/knifty-0.4.2 =x11-themes/liquid-0.9.7 =x11-themes/reinhardtstyle-0.8.2 =x11-themes/ridge-0.3.2 =x11-themes/thinkeramik-3.2.1 =kde-misc/ksplash-engine-moodin-0.4.2 =net-im/sim-0.9.4.3 =kde-base/libkdepim-3.5.7-r1 =kde-base/libkpimexchange-3.5.7 =x11-misc/rss-glx-0.8.1-r4 =kde-base/kaudiocreator-3.5.7 =kde-base/libkpimidentities-3.5.7 =kde-base/kontact-3.5.7-r1 =kde-base/kaddressbook-3.5.7 =kde-base/akregator-3.5.7-r1 =kde-base/knotes-3.5.7 =kde-base/kpilot-3.5.5 =kde-base/kdepim-kresources-3.5.7-r1 =kde-base/korganizer-3.5.7-r1 =kde-base/kontact-specialdates-3.5.7 =kde-base/kdemultimedia-arts-3.5.7 =kde-base/noatun-3.5.7 =kde-base/kaboodle-3.5.7 =kde-base/kghostview-3.5.7 =kde-base/kmix-3.5.7 =sys-apps/dbus-1.0.2-r2 =dev-libs/dbus-glib-0.73 =x11-wm/fluxbox-1.0_rc3 =kde-misc/kompose-0.5.4 =media-libs/xine-lib-1.1.4-r2 =x11-wm/compiz-0.5.0 =media-video/kmplayer-0.9.4a-r1 =kde-base/kdeprint-3.5.7 =kde-base/kpdf-3.5.7-r1 =kde-base/kdepasswd-3.5.5 =sys-apps/hal-0.5.9-r1 =kde-base/kdebase-kioslaves-3.5.7-r1 =app-cdr/k3b-0.12.17 =kde-base/khelpcenter-3.5.7 =kde-base/kcontrol-3.5.7-r1 =kde-base/konqueror-3.5.7-r2 =kde-base/konsole-3.5.7 =kde-base/kmail-3.5.7-r2 =kde-base/kdesktop-3.5.7 =media-sound/amarok-1.4.6-r1 =kde-base/konqueror-akregator-3.5.7 =x11-themes/baghira-0.8 =kde-misc/yakuake-2.7.5 =kde-base/kdm-3.5.7 =gnome-base/libbonoboui-2.16.0 =gnome-base/gnome-mount-0.6 =gnome-base/libgnomeui-2.16.1 =dev-python/gnome-python-extras-2.14.2-r1 =media-plugins/audacious-plugins-1.3.3 =app-admin/conky-1.4.6|grep "3.5.5" [/code]

----------

## sefirotsama

Se me olvidaba... la libreria que peta principalmente es el libexpat.so.0 (ya he dicho que el revdep rebuild falla al compilar) entre otras... pero esa es la que más "polojete mesta dando".

Agradezco vuestra ayuda... (aunque veo venir malos tiempos y me rallo mucho).

Serà que debo pasarme a otra distro? Por favor que alguien me saque esta tentación...

----------

## x_MiTH_x

Pues a mi me ha pasado algo muy parecido con GNOME. El revdep-rebuild también me daba errores con algún paquete así que al final tiré de lista a mano y con emerge --oneshot y listas de paquetes he conseguido recuperar el sistema. 

En un principio se lo achacaba a que tengo metidos ebuilds con layman para el GNOME testing, pero si a ti te pasa con KDE puede que el problema sea otro. 

A mi al final me quedan 4 o 5 ebuilds que me tiran error. Todavía no me he puesto a mirar detenidamente porque.

Edito para aclarar que mi paquete problemático también fue el libexpat, no es que escriba aquí sin motivo  :Wink: 

----------

## Cereza

¿Es posible que tu /var/lib/portage/world estuviera corrupto? si fuera así, emerge --depclean hubiera borrado casi todo tu sistema si lo hiciste cuando estabas desinstalando paquetitos. Eso muy probablemente podría haber sido la causa de tu problema. A mi me sucedió una vez pero por suerte me dí cuenta a tiempo de que --depclean pretendía  borrar demasiadas cosas. La solución en mi caso, (antes de que --depclean lo borre todo) es el comando regenworld, que rehizo mi /var/lib/portage/world

```
!!! Multiple versions within a single package slot have been 

!!! pulled into the dependency graph: 

 

('ebuild', '/', 'kde-base/libkonq-3.5.5', 'merge') pulled in by 

 ('ebuild', '/', 'kde-base/kdepasswd-3.5.5', 'merge') 

 

('ebuild', '/', 'kde-base/libkonq-3.5.7', 'merge') (no parents) 

 

It may be possible to solve this problem by using package.mask to 

prevent one of those packages from being selected. However, it is also 

possible that conflicting dependencies exist such that they are 

impossible to satisfy simultaneously. If such a conflict exists in the 

dependencies of two different packages, then those packages can not be 

installed simultaneously.
```

Como dice el error, enmascara los paquetes de kde 3.5.5 para que no bloqueen a los de 3.5.7

En cuanto a una solución, creo que deberias descoprimir stage3 encima de tu sistema para tener una raiz limpia y asegurarte de que no te falta ningún paquete críquito, compilar system, para despues empezar a recompilar poco a poco tu sistema. Además creo que deberías hacerlo con un portage limpio, es decir, sin overlays y paquetes desenmascarados, y una vez reparado el daño meter tus cosas.

A las malas si está verdaderamente roto y necesitas hacer una instalación limpia, usa tus viejos etc, home, distfiles y demás... teniendo eso, un stage, portage y tus distfiles, no deberías necesitar internet en teoría.

La verdad es que no creo que sea un motivo para cambiar de distribución, teniendo en cuenta que pueden haber sido muchas cosas, como un mal apagado que haya corrompido, como dije, el archivo world.

[quote=x_MiTH_x]Pues a mi me ha pasado algo muy parecido con GNOME. El revdep-rebuild también me daba errores con algún paquete así que al final tiré de lista a mano y con emerge --oneshot y listas de paquetes he conseguido recuperar el sistema.[/quote]

Los paquetes que se compilan con --oneshot no se actualizaran, y además, si alguna vez quieres hacer emerge --depclean para borrar dependencias huerfanas, los borrará.

----------

## Howlett

Lo del libexpat.so.0 es algo que nos ha pasado a los que usamos Gnome y a más gente. Por lo que he visto por ahí tienes dos soluciones, una de ellas temporal:

1) Crear un enlace simbólico de liexpat.so a libexpat.so.0 . Esto te compilará los paquetes (conmigo lo hizo), pero te darán problemas. Lo que yo hice en su momento fué esta solución temporal y después eliminé el enlace y continué por el siguiente punto.

2) Ejecutar el siguiente comando:

```
revdep-rebuild -X --library libexpat.so.0
```

También puedes ejecutar el comando anterior del revdep-rebuild directamente sin pasar por el punto 1. Por lo que he visto funciona bien para todo el mundo.

----------

## achaw

Si lees otros posts de este mismo foro, a muchos nos ha pasado lo mismo con expat...A mi revdep-rebuild tampoco me funciono y tuve que hacer el enlace "a mano".....Como dice el amigo Howlett, de mas esta decir que la solucion 2 que el plantea no me funciono.

Saludos

----------

## chumi

No se si te servirá de ayuda, pero yo necesité emerger unos cuantos paquetes a mano despues de actualizar expat para poder compilar el resto. Son basicamente utilidades que se utilizan desde el emerge para hacer los chequeos, y que al petar por culpa de libexpat paran el emerge. Los paquetes que tuve que reinstalar fueros estos:

gettext 

XML-Parser

dbus-glib

dbus

fontconfig

Saludos!!

----------

## pcmaster

Pueas a mí el otro día, tras hacer un emerge --sync y luego un emerge world, algunas aplicaciones fallaban al compilar. Al final tuve que hacer un emerge system y, tras ello, HORROR, las aplicaciones que ya estaban abiertas seguian funcionando, pero no podía abrir nuevas instancias: daba error en libexpat.so.0.

El fallo afectó no solamente a las aplicaciones más importantes (firefox, openoffice-bin, al terminal, etc), sino que el propio Xorg, al cerrarlas ya no se podían ejecutar de nuevo. Como no, error en libexpat.so.0.

Solución: emerge world y, recompilar todo. Tras más de 20 horas compilando los 798 paquetes, no sin fallar y tener que continuar con emerge --resume varias veces (algunos paquetes como las GTK+ fallaron) cuando acabé emergí los paquetes que habían fallado y, ahora sí, compilaron bien.

Por cierto, un emerge --world compila todos los paquetes, incluídos los que ya están en el system. y por eso algunos paquetes se compilaron dos veces. Curiosamente, la glibc la primera vez (al compilarla con el system) tardó unos 45 minutos, y la segunda vez (con el world) más de una hora. ¿Sabéis por qué puede ocurrir esto?

----------

## x_MiTH_x

 *Quote:*   

> Los paquetes que se compilan con --oneshot no se actualizaran, y además, si alguna vez quieres hacer emerge --depclean para borrar dependencias huerfanas, los borrará.

 

Lo utilizo porque no quiero que se queden paquetes "secundarios o dependientes" en el world. Obviamente todos los paquetes que necesito ya están emergidos por el método tradicional y se van a actualizar siempre.

----------

## ps2

todas estas movidas os han pasado con "arch" o "~arch"? Es sólo curiosidad. Si no es ~arch, realmente es inaceptable...

----------

## Howlett

 *ps2 wrote:*   

> todas estas movidas os han pasado con "arch" o "~arch"? Es sólo curiosidad. Si no es ~arch, realmente es inaceptable...

 

Con "arch", por lo menos en mi caso. Desde luego es un problema gordo el que ha provocado el paquete Expat este. Espero que no vuelva a pasar.

----------

## Inodoro_Pereyra

 *ps2 wrote:*   

> todas estas movidas os han pasado con "arch" o "~arch"? Es sólo curiosidad. Si no es ~arch, realmente es inaceptable...

 

A mí también me pasó, estoy en la rama estable y no uso ni kde, ni gnome... En xfce4.4 me fallaba por ejemplo algo tan básico como el terminal por culpa de nuestra vieja amiga expat... En E17, ni siquiera podía iniciar sesión.

Como sea, ya salí del paso, después de bastantes horas de compilación.

Salud!

----------

## sefirotsama

Para empezar haré un regen world desde el chroot i bajaré más paquetes un stage3 y esta misma pagina fuera de linia (además del manual por si acaso lo borré)

Gracias a todos por las respuesta, snif, os quiero! Os quiero a todos! Gracias!

(creo que me ha dado un brote Bisbal)

Ya os contaré como me va y... si em salgo de esta tranquilamente prometo hacer alguna contribución (algo más grande) a la comunidad (no como la guia LAMP de este foro).

Una saludo! Os quiero!

xDD

P.S.

 *ps2 wrote:*   

> todas estas movidas os han pasado con "arch" o "~arch"? Es sólo curiosidad. Si no es ~arch, realmente es inaceptable...

 

Ha pasado con la estable y además el portage era el ultimo estable que habia en la fecha!!!!

----------

## i92guboj

 *ps2 wrote:*   

> todas estas movidas os han pasado con "arch" o "~arch"? Es sólo curiosidad. Si no es ~arch, realmente es inaceptable...

 

¿Inaceptable?

Gentoo no puede evitar que una librería cambie su API o que un update rompa el ABI de las aplicaciones. Es totalmente imposible de evitar. La solución es recompilar las aplicaciones que usan esa librería contra la nueva versión de la librería. Tarde o temprano, tiene que ocurrir, si queremos añadir funcionalidad a una librería (expat, en este caso).

La ventaja de una metadistro basada en código fuente es que podemos hacer esto. 

En una distro binaria es imposible, y algo tan simple como un update de expat, requeriría una reinstalación de una nueva versión de la distro o al menos de todos los binarios enlazados con dicha librería. Porque todos los precompilados se romperían si simplemente actualizamos la librería.

----------

## ps2

 *i92guboj wrote:*   

>  *ps2 wrote:*   todas estas movidas os han pasado con "arch" o "~arch"? Es sólo curiosidad. Si no es ~arch, realmente es inaceptable... 
> 
> ¿Inaceptable?
> 
> Gentoo no puede evitar que una librería cambie su API o que un update rompa el ABI de las aplicaciones. Es totalmente imposible de evitar. La solución es recompilar las aplicaciones que usan esa librería contra la nueva versión de la librería. Tarde o temprano, tiene que ocurrir, si queremos añadir funcionalidad a una librería (expat, en este caso).
> ...

 

Sí, es absolutamente inaceptable. La rama es estable, pues estable debe de ser. Si va a crear problemas, que avisen como mínimo no? O tampoco? No habría sido más facil hacer que portage actualizara dicha libreria y posteriormente los paquetes necesarios? Y si no se podía hacer algo así, dejaron instrucciones en algun sitio? Hay algo así en gentoo? En FreeBSD está el /usr/ports/UPDATING con sus notitas por si hay alguna movida.

----------

## sefirotsama

Yo también pienso que es inaceptable, i92juboj (6thpink no te olvidaremos, xD). Una rama estable en una distribución de reputación y alto prestigio como es gentoo no deberia permitirse estas cosas... no sé que decir al respecto... tal vez se deberia haber preparado especialmente el ebuild de la libreria en cuestión para que, al actualizarla comprobara enlaces y demás (con un condicional por si la instalción es nueva).

Vale, somos muy bocas y esto es codigo abierto y si tanto nos molesta tenemos o bién puerta para irnos por patas o bién tofo el codigo fuente del mundo y la documentación (junto a la comunidad). No me cabe en la cabeza quedarme con el culo al aire y, temporalmente), verme obligado a recurrir a otra distribución para poder seguir trabajando (y copiar mis configs al home).

Por no decir que YO tenia gentoo en un pedestal muy alto... y se me ha caido (encima además) es la primera vez que me deja en la estacada y de lleno... mi orgulloso y pretencioso escritorio capaz de dejar abierto de vocas cualquier ubuntero cutre con chanclas y calcetines (por no hablar de sn00bs windowseros que se flipan con un fondo de pantalla) me ha convertido el flamante desktop en un perfecto sistema con linia de comandos en el que puedo chatear conectarme a internet, escuchar musica,(mp3blaster) leer el mail (es webmail) y hacer lo mismo de antes... en modo texto (escepto el brillante KONTACT con korganizer, etc). Sea como sea se quedan con la boca abierta.

Esto me ha dolido... sin embargo me siento como un pecador por usar el ubuntu que tanto he criticado dias/años antes... realmente esto nos puede hacer reaccionar un poco a todos... y ser menos radiKales (kon K de Kde). Ni yo criticar tanto a ubuntu ni... pasarse halagando a gentoo tiene sis más y sus menos y este post lo demuestra.

Eso sí, la comunidad se deberia llevar el premio Novel por el compañerismo y la sodilaridad... entre sus miembros...

Espero poder volver a sentirme orgulloso de gentoo algún día...

En todo caso sigo con mi reparación a ver si lo consigo... espero no haberme excedido con el post, y no lo digo por su largada.

P.S. Y ahora, que alguien me desubuntice ahora... que cuanto más lo uso más me doy cuenta de lo que me faltaba por arreglar de gentoo (desde el wifi maldito hasta detallitos que siempre están pendientes)

----------

## achaw

Yo estoy un poco de acuerdo. Siempre estuve en ~arch y son cosas que puedo esperar que pasen a veces. Me extraño mucho verlo en la rama estable.

Encontre un post tratando el tema en los foros en ingles, incluso ya hay abierto un bug si no me equivoco:

https://forums.gentoo.org/viewtopic-t-576847.html

Saludos

----------

## i92guboj

 *ps2 wrote:*   

>  *i92guboj wrote:*    *ps2 wrote:*   todas estas movidas os han pasado con "arch" o "~arch"? Es sólo curiosidad. Si no es ~arch, realmente es inaceptable... 
> 
> ¿Inaceptable?
> 
> Gentoo no puede evitar que una librería cambie su API o que un update rompa el ABI de las aplicaciones. Es totalmente imposible de evitar. La solución es recompilar las aplicaciones que usan esa librería contra la nueva versión de la librería. Tarde o temprano, tiene que ocurrir, si queremos añadir funcionalidad a una librería (expat, en este caso).
> ...

 

Como he explicado arriba, no es cosa de Gentoo. El cambio es en la librería, y Gentoo no puede soluiconar eso. 

 *Quote:*   

>  Si va a crear problemas, que avisen como mínimo no? O tampoco?

 

En eso estoy de acuerdo. Ese es otro asunto muy distinto. El hecho de que un cambio de API rompa los enlaces dinámicos es inevitable. No es algo difícil de entender. Esto no es cosa ni de Gentoo, ni siquiera de Linux. Pasará lo mismo en cualquier SO que use dicha librería y se actualice a dicha versión, eso incluye a FreeBSD, si es que libexpat se usa en BSD. La recompilación es necesaria. Punto.

 *Quote:*   

> 
> 
>  No habría sido más facil hacer que portage actualizara dicha libreria y posteriormente los paquetes necesarios? Y si no se podía hacer algo así, dejaron instrucciones en algun sitio? Hay algo así en gentoo? En FreeBSD está el /usr/ports/UPDATING con sus notitas por si hay alguna movida.

 

Portage no tiene los mecanismos para comprobar si hay un cambio de API y re-emerger paquetes en dicho caso. La única opción es revdep-rebuild. Es cierto que un anuncio oficial sería bueno. Pero también es cierto que quién no se entera, es porque no quiere.

Hay bastantes hilos repitiendo lo mismo hasta la saciedad en los foros, por no hablar de las listas de correo.

http://www.google.com/search?num=100&hl=es&q=site%3Aforums.gentoo.org+expat&btnG=Buscar&lr=

----------

## Inodoro_Pereyra

Dejando de lado que la actualización de expat me dejó sin poder trabajar medio día y mucha gracia no me hizo. No veo por que tanto alboroto.

No se me cayó nada de ningun pedestal, pero si coincido en que una advertencia hubiera estado bien.. Al menos podría haber esperado hasta el fin de semana por ejemplo, si hubiera sabido la que se venía en lugar de cortarme media jornada laboral compilando.

Salud!

----------

## Cereza

Vengaa ¿sois hombres o qué? : P Que tampoco es para montar ningún drama.

Como i92guboj ha dejado claro, esto no es un fallo de Gentoo. Y aunque lo fuera no me parece lógico decir que es absolutamente inaceptable, ni poner el grito en el cielo, por los problemas que puedan surgir del trabajo de una gente que hace Gentoo por que sí, libre y sin beneficio propio, a los que no podemos exigir nada. En las distribuciones binarias es infernal hacer el más simple update sin cargarse toda una telaraña de depencencias. Yo me he cargado varias veces mi sistema y he tenido que hacer una instalación nueva, en dos ocasiones por fallos mios y en otra no estoy segura, pero probablemente también, y no me he cabreado tanto, claro qué, todos somos más tolerantes con nuestros errores que con los de los demás

----------

## ekz

 *ebuild de expat wrote:*   

>       ewarn "Please note that the soname of the library changed!"
> 
>         ewarn "If you are upgrading from a previous version you need"
> 
>         ewarn "to fix dynamic linking inconsistencies by executing:"
> ...

 

Yo al comenzar el revdep-rebuild, y ver que fallaban algunas compilaciones (la quinta de 80), hice un downgrade de expat. 

Y creo que lo enmascararé

SAludos

----------

## i92guboj

 *ekz wrote:*   

>  *ebuild de expat wrote:*         ewarn "Please note that the soname of the library changed!"
> 
>         ewarn "If you are upgrading from a previous version you need"
> 
>         ewarn "to fix dynamic linking inconsistencies by executing:"
> ...

 

Solo señalar dos cosas:

1.- Ocasionalmente, tendrás que actualizar, en un momento u otro.

2.- libexpat es una librería que se usa para manejar código xml. Esto incluye páginas como las mismas de la web oficial de Gentoo. Apache, konqueror, y probablemente casi todo lo que tenga una use flag para xml, enlaza con expat. Esto quiere decir que si no actualizas, y hay problemas de seguridad que han sido parcheados en la última versión de libexpat, todos los programas que enlacen con dicha librería serán vulnerables de una forma u otra, a no ser que uses la última versión.

Chicos, on es tan difícil: simplemente actualizar libexpat, y luego usad revdep-rebuild para recompilar todo lo que enlace a dicha librería. Puede que necesiteis alterar el orden de la lista de paquetes que revdep-rebuild generará, pero por lo demás, no veo donde está el problema.

----------

## i92guboj

Por cierto, esto pasa todos los días con todo tipo de paquetes, y jamás a nadie se le ha ocurrido que esto sea un fallo. Es por esto que revdep-rebuild existe. Se usa a diario (o así debería ser), y nunca nadie ha tenido problema en hacerlo.

La única diferencia es que libexpat es una librería más comunmente usada, y por tanto el cambio afecta a más paquetes. Por lo demás, no hay diferencia con cualquier otro caso. Si tuvieran que avisarnos cada vez que tenemos que ejecutar revdep-rebuild los desarrolladores pasarían más tiempo haciendo eso que desarrollando  :Razz: 

----------

## ps2

El problema podrá haberse repetido hasta la saciedad... en los foros. Pero a la mayoría de la gente no nos sobra tiempo para pasarnos el dia en foros. Justo estoy teniendo ahora un poco de tiempo libre y estoy rondando más por los foros.

Que cambien una libreria no es cosa de gentoo. Pero sí es cosa de gentoo saber mantener los ports. No exijo nada, soy gentooza dsd 2002 que yo recuerde y no quiero ni me gusta ningún otro linux más que gentoo. Y si pudiera colaborar con el portage lo haría, pero no tengo el tiempo, ni tampoco los conocimientos, al menos por el momento.

Saludos a todos.

----------

## Zagloj

Simplemente es una distro que requiere tiempo de mantenimiento, es como tener una mascota, si no puedes cuidarla..., en cuanto a los foros no hay que estar tan atento, sólo si hay un problema se pasa uno por "portage and programming", porque de eso es el problema, y hay allí un hilo fijo en este caso, en otros una simple búsqueda basta, antes de actualizar conviene informarse, yo si estoy en un momento "delicado" en el que no quiero desastres, no toco nada, ya actualizaré más adelante.

 Saludos y salud para todos  :Wink: 

Pd Es sólo mi muy personal opinión.

----------

## ps2

Tu firma es buenísima xD

No sé, yo también tengo el problema este del expat además de otros (otras movidas mías) y creo que reinstalaré. Además me gusta instalar gentoo, es una sensación agradable, quizá estoy loco xD  Pero bueno, eso si soluciono cierto problema de hardware que me está dando la máquina  :Confused: 

----------

## gringo

 *Quote:*   

> El problema podrá haberse repetido hasta la saciedad... en los foros

 

erm, no, hay un aviso bien gordo en el propio ebuild. Elog es tu amigo.

 *Quote:*   

> Que cambien una libreria no es cosa de gentoo. Pero sí es cosa de gentoo saber mantener los ports.

 

que quiere decir "mantener los ports" ?  Todas las distros han pasao por esto y ahora le toca a gentoo, no entiendo cuál es el problema ...

saluetes

----------

## ps2

Nada, el problema es solamente que nos ha dejado con problemas en el sistema y pérdida de tiempo innecesario a mucha gente. Donde está el aviso? donde esta ni siquiera un mensaje del portage sobre el problema que proporcione una URL a la que acudir e informarse?

----------

## gringo

 *Quote:*   

> Donde está el aviso? 

 

al instalar expat te sale el siguiente mensaje al final :

 *http://gentoo-portage.com/AJAX/Ebuild/49274/View wrote:*   

> pkg_postinst() {
> 
> 	ewarn "Please note that the soname of the library changed!"
> 
> 	ewarn "If you are upgrading from a previous version you need"
> ...

 

te están diciendo explícitamente que hagas eso o vas a tener problemas. 

 *Quote:*   

> Nada, el problema es solamente que nos ha dejado con problemas en el sistema y pérdida de tiempo innecesario a mucha gente

 

y que prefieres ? quedarte con el anterior expat hasta el final de los días ? No hay otra forma de actualizar, si no te gusta pues en fin, no actualices.

Si el problema es que lleva mucho tiempo recompilar todo el software que dependa de expat, sinceramente creo que os habéis equivocado de so.

saluetes

----------

## ps2

Digo un mensaje en el portage porque no puedo quedarme mirando la pantalla a ver que dice por cada paquete que pone.

De todas formas reinstalaré, y no, no me he equivocado de sistema operativo, gentoo es mi opción para escritorio desde hace años y no la voy a cambiar por algo así xD

----------

## Howlett

Yo tampoco creo que sea para pensar que Gentoo ha caído.

Cuando me pasó el problema fue cuando actualizé Gnome, y aunque las pasé putas, reconozco que me sirvió para enfrentarme a un problema de compilaciones y dependencias que me hizo aprender más sobre este SO. Así que mira, no hay mal que por bien no venga.

De momento, y con estos fallos y todo, me sigo quedando con Gentoo de todas las distros que he probado.

----------

## gringo

 *Quote:*   

> Digo un mensaje en el portage porque no puedo quedarme mirando la pantalla a ver que dice por cada paquete que pone. 

 

pues deberías mirar lo que cuenta portage cuando instala algo, sobre todo para evitar "sorpresas" como esta.

Además, nadie te dice que te quedes mirando a nada, te puedes enviar los logs de portage al email p.ej.

http://www.gentoo.org/doc/es/handbook/handbook-x86.xml?part=3&chap=1#doc_chap4

 *Quote:*   

> De momento, y con estos fallos y todo, me sigo quedando con Gentoo de todas las distros que he probado

 

esto no es un fallo de gentoo, es una simple actualización, todas las distros han pasao por esto. Y no va a ser la última vez que pase esto.

saluetes

----------

## i92guboj

El problema de los avisos es que nadie los lee. El mismo ebuild expat-2.0.1.ebuild nos dice esto:

```

pkg_postinst() {

        ewarn "Please note that the soname of the library changed!"

        ewarn "If you are upgrading from a previous version you need"

        ewarn "to fix dynamic linking inconsistencies by executing:"

        ewarn "revdep-rebuild -X --library libexpat.so.0"

}

```

Pero claro, como el anuncio nadie lo lee, pues luego vienen los problemas.

Antes la gente se quejaba de que los anuncios se quedaban perdidos entre tanto emerge en los updates largos. Ahora, salen todos al final, para que se puedan ver, juntitos. Pero da absolutamente igual, porque hadie los lee. En el foro el tema arde, hay cientos de posts sobre libexpat, pero da igual porque nadie es lo suficientemente solidario como para escribir "expat" en el cuadro de búsqueda, en lugar de llenar el foro con más spam sobre el mismo tema, una y otra vez. Si se anunciara en la web de Gentoo con letras grandes verde fosforito sobre fondo negro y parpadeando, daría igual, porque la gente seguiría sin enterarse. Y es que para mantenerse desinformado no hay como la falta de interés.

Yo creo que los medios al alcance del usuario son más que suficientes. Otro problema muy distinto es que la gente no quiera usarlos, simplemente porque no coinciden con su ideal de como las cosas deberían ser. Las herramientas de logeo son muy potentes, podemos incluso enviar un disgest con los resultados a nuestro mail, si no tenemos ganas de mirar en los logs, o de estar atentos a un emerge. Tenemos una herramienta para resolver dependencias y analizar la consistencia ldd de los binarios, y todavía nos quejamos. Y es que aunque emerge hiciera el revdep-rebuild por nosotros, aún encontraríamos algo de qué quejarnos. No os quepa la menor duda.

Somos muy vagos, y vamos a meternos todos en el mismo saco, al menos, en lo que toca a la administración de nuestros sistemas. Lo menos que se puede pedir, es que una tarea de administración requiera la atención de root (si, tú, no mires hacia atrás buscando a otro  :Razz:  ). Un mínimo, aunque sea. Si alguien piensa que ese tipo de tareas deberían ser realizados por el SO de forma autónoma y sin que tú tengas que preocuparte de nada, existe una empresa que fabrica un sistema operativo alternativo que hace eso:

http://es.wikipedia.org/wiki/Microsoft

 :Twisted Evil: 

Por si acaso, aclaro que esto son solo unas reflexiones, y no van dirigidas a nadie en concreto. Lo que hace el aburrimiento  :Razz: 

----------

## ghoute

 *i92guboj wrote:*   

> El problema de los avisos es que nadie los lee. El mismo ebuild expat-2.0.1.ebuild nos dice esto:
> 
> ```
> 
> pkg_postinst() {
> ...

 

y yo que lo hago haciendo 

```

ln -s /usr/lib/libexpat.so /usr/lib/libexpat.so.0

```

donde a su ver libexpat.so es un link dinámico a la versión de la librería más reciente instalada

----------

## i92guboj

 *ghoute wrote:*   

>  *i92guboj wrote:*   El problema de los avisos es que nadie los lee. El mismo ebuild expat-2.0.1.ebuild nos dice esto:
> 
> ```
> 
> pkg_postinst() {
> ...

 

Ya lo explico en otro hilo, no se si en el foro español o el inglés, no recuerdo.

Eso no es una solución, sino un parche que -potencialmente- puede traer problemas.

El cambio de nombre de la librería se debe a la simple razón de que el API de dicha librería ha cambiado, rompiendo la compatibilidad con las anteriores versiones, y de paso, el ABI de todos los programas que enlazan a dicha librería. Todos los programas que estén compilados con la versión anterior NECESITAN ser recompilados contra la nueva versión de dicha librería, y estarán rotos hasta que hagas eso, por muchos enlaces que pongas. El cambio de nombre se ha hecho precisamente para forzarte a recompilar, porque es necesario, y no por gusto, ni es que los devs de Gentoo se regocijen haciéndonos desgraciados. (Aunque como ya digo más arriba, este cambio es "upstream", y no tiene nada que ver con Gentoo, ni siquiera con Linux).

Si tu te saltas eso con un enlace, lo único que estás haciendo es romper tu sistema. Puede que tengas suerte y no ocurra nada, a la larga, todo será recompilado de una u otra forma. Pero esas soluciones no suelen ser buenas. Antes de hacer algo así, debería pararte y preguntarte lo siguiente: "a ver, un segundo, ¿por qué funciona esta solución? ¿sé lo que estoy haciendo o es solo pura casualidad que todo parezca funcionar?". Si en el futuro tienes más complicaciones con libexpat, vas a sufrir mucho más para poder arreglarlas, porque cuando introduces una modificación por tu cuenta y a mano en el sistema, no hay forma de que nadie la pueda conocer, y por tanto, no podrán ayudarte por mucho que lo intenten.

----------

## Noss

sefirotsama, yo para la próxima actualizaría cuando tubiera tiempo de arreglar posibles cambios así. De todas formas no es para tanto, tienes todos los ficheros de configuración, así que lo peor ya lo tienes echo... Y un último apunte, seguro pero seguro que pongas la distro que pongas o el sistema operativo que pongas, al final volverás a gentoo, aunuque tardes x meses o años... Eres un tío como la mayoría de los que estamos aquí, que nos gusta enrredar en todo, estar tocando todo y saber por qué funciona, y no conformasnos con que funcione... Así que tarde o temprano volverás a gentoo. 

Por mi parte sería una pena que un usuario y compañero de distro como tu se fuera... Espero que lo pienses bien resuelvas tu problema y decidad quedarte aquí.

Mirame a mi como ejemplo a veces estoy meses sin poner un solo post sin tocar nada, pero no tardo en tocar por tocar por experimentar y aprender... Algunas veces con hardware otras con software... pero ahí estamos siempre tocándolo todo.... Y por mucho que este esos meses sin escribir un post y dejando mi gentoo como estaba no tardo en merter mano a algo o instalarle la gentoo a otro por puro placer. 

Si como yo creo tú eres parecido a mi, tranquilo que tarde o temprano volverás a gentoo y aquí como siempre todos te esperarán con los brazos abiertos

un saludo y suerte con tu problema!

EDITADO: Por aquí rula un post en el que pacho2 explicaba la forma "correcta" de actualizar el sistema, o al menos la que él usaba como correcta que yo he "copiado" y que hasta ahora no he tenido problemas

----------

## sefirotsama

a ver i92guboj, si estamos de acuerdo de que que se ha de recompilar... Es más me estoy pasando el dia y la noche compilando... pero el comando que tanto crees que debe arreglar todo el embrollo ( revdep-rebuild -X --library libexpat.so.0 ) me dice que he de emerger 3 kilos de papel con el nombre de nosecuantas cosas (vale, 271 no es tanto) y lo mejor es que después, me deja tirado cuando comienza la primera compilación... precisamente por la propia libreria que falla...

¿Eso seria un error circular? Como si tubieras dos pies izquierdos y caminaras en circulos... EL caso es qu eme esperé más de una semana a actualizar world por miedo a que pasara algo. Tengo un amigo de gentoo cerca de casa (aunque el es gnomero), no acostumbra a usar nunca el revdep-rebuild pero le peto todo, igual que a mi y le funcionó, se arregló, sin más...

¿y porqué a mi no?

No es el cambio de libreria, es que me he quedado con el culo al aire, es que me ha fallado todo, el revdep-rebuild lo hago sistemáticamente siempre, sobretodo antes y despues del depclean... pero esta vez tururú. Y si he exagerado en el post, disculpas, porqué yo sí me leo la info que me deja portage al acabar, los errores y alguna vez hasta los logs (sin embargo como me falta tiempo no leo la web ni las listas de correo y a duras penas parte del foro).

Estamos de acuerdo en que aquí se compila, igual que no se va a ir a un chino a pedir un huevo frito, aquí no se le piden muchas cosas... solo queria que el comando funcionara... pero no... es más he intentado emerger paquete a paquete cada uno me daba siempre el mismo error... y hasta las narices pues a tomar viento...

Lo que no encuentro lógico es que no se ejecute automáticamente dicho comando tras el cambio de librería (aunque si no me fué no creo que me hubiera servido).

De todas maneras he borrado toda la raiz escepto /etc y /home y el .config del kernel y poco más. No era lo que queria ahcer, pero ya puestos a arreglar el sistema, espero que me sirva también de paquetes chorras que tenia instalados y cosas inutiles que se acumulan con el tiempo y se olvidan...

Ya se que no deberiamos quejarnos tantos y que es codigo abierto con "absolutely no warranty" como dicen los de ubuntu. Que pasara con quien tenga un cluster enorme con gentoo y deba para el servicio que ofrece por un problema tecnico? Són detalles que la distribución DEBE solventar aunque no sea culpa suya, da =.

Si se despista y no va con cuidado...

En fin se podria aparcar ya el tema

----------

## sefirotsama

Noss acabo de leer lo que me has puesto. He exagerado en el post que dije que gentoo se me cayó encima... realmente me he quedado sin poder trabajar en el portatil... y lo que me pareció vergonzoso es recurrir a una distribución externa a gentoo y por sorpresa mi unica opción de salvarlo (revdep) no iva...

Estoy de acuerdo con recompilar... pero que funcione...

De todas maneras si soy optimista puedo decir que he aprovechado para pegarle un repaso entero al ordenador y reinstalar, cosa que queria hacer tiempo atras...

No hay mal que por bien no venga. (espero)

 *Noss wrote:*   

> Por mi parte sería una pena que un usuario y compañero de distro como tu se fuera... Espero que lo pienses bien resuelvas tu problema y decidad quedarte aquí.

 

Gracias, de verdad, no me esperaba esto.... insisto me parece que si hiciéramos un encuentro algunas birras gratis caerian...

----------

## i92guboj

 *sefirotsama wrote:*   

> a ver i92guboj, si estamos de acuerdo de que que se ha de recompilar... Es más me estoy pasando el dia y la noche compilando... pero el comando que tanto crees que debe arreglar todo el embrollo ( revdep-rebuild -X --library libexpat.so.0 ) me dice que he de emerger 3 kilos de papel con el nombre de nosecuantas cosas (vale, 271 no es tanto) y lo mejor es que después, me deja tirado cuando comienza la primera compilación... precisamente por la propia libreria que falla...
> 
> 

 

Sobre el número de paquete rotos no hay alternativa. Tendrás que recompilar todo lo que enlace con libexpat.

 *Quote:*   

> 
> 
> ¿Eso seria un error circular? Como si tubieras dos pies izquierdos y caminaras en circulos... EL caso es qu eme esperé más de una semana a actualizar world por miedo a que pasara algo. Tengo un amigo de gentoo cerca de casa (aunque el es gnomero), no acostumbra a usar nunca el revdep-rebuild pero le peto todo, igual que a mi y le funcionó, se arregló, sin más...
> 
> ¿y porqué a mi no?
> ...

 

Estas cosas no se arreglan sin más. La única forma de que los paquetes dependientes en libexpat se "arreglen" tras un cambio del api de la librería, es recompilarlos. O bien tu amigo usó algún truco sucio como el del link, o bien simplemente enmascaró la versión nueva de expat, o bien recompiló world dos veces, como -absurdamente- hacen muchos cada dos días por alguna razón que no alcanzo a comprender.

El problema de revdep-rebuild es que no es perfecto. Imagina, por ejemplo, que el paquete A y el paquete B dependen en expat, pero al mismo tiempo el paquete B depende en el A. Sin embargo, por alguna razón inimaginable, revdep-rebuild puede intentar recompilar los paquete en el orden incorrecto. Si compila A contra las nuevas libexpat, entonces A estará bien, y podrás compilar B usando la nueva versión de libexpat, y la nueva versión de A que también ha sido compilada con las nuevas libexpat. Pero si revdep-rebuild lo intenta al revés (es decir, compila antes B, y luego A) entonces puede ser que B no compile, porque depende en A, y A no está en un estado consistente debido a que no ha sido compilada contra las nuevas libexpat. El problem de revdep-rebuild, es, por tanto, un problema de orden. Cuando esto para, simplemente usa revdep-rebuild -p, para ver lo que se emergería, pero sin emergerlo. Y luego ve emergiendo paquetes, si uno falla, déjalo, y sigue con el siguiente. Al final, vuelve a intentar con los que fallaron antes, y así hasta que estén todos recompilados. 

Cuando acabes, revdep-rebuild no debería reportar nada.

 *Quote:*   

> 
> 
> Ya se que no deberiamos quejarnos tantos y que es codigo abierto con "absolutely no warranty" como dicen los de ubuntu. Que pasara con quien tenga un cluster enorme con gentoo y deba para el servicio que ofrece por un problema tecnico? Són detalles que la distribución DEBE solventar aunque no sea culpa suya, da =.
> 
> 

 

El que tiene un cluster enorme, no hace updates sin antes testearlos en una subred para prever posible problemas y cosas de este estilo. Ningún servidor de producción hace eso, a no ser que su administrador tenga problemas mentales. Precisamente, porque se supone que ese administrador está ahí para eso, y no debe dar nada por sentado. Los servidores y clusters grandes no se pueden permitir el lujo de las actualizaciones a ciegas, como una máquina de escritorio o un servidor casero.

Como ya dije arriba, tan solo eran reflexiones  :Razz:  Por supuesto, todo el mundo tiene derecho a quejarse, otra cosa es que vaya a servir para algo jeje, Gentoo no es perfecto, sin embargo, estos hilos tampoco son la forma de mejorarlo. Si se ve algo que no es satisfactorio, lo suyo es contrastar opiniones, informarse, y si se cree oportuno, abrir un bug en bugzilla. Todo lo demás, es discusión inútil y vacía, porque si nosotros no tenemos tiempo para gastarlo en el foro, los devs de Gentoo tienen mucho menos. Por tanto, si revdep-rebuild no va como debiera, o se quiere una nueva característica en portage, lo suyo es entrar en contacto con el equipo de portage y ponerse manos a la obra, no necesariamente programando.

----------

## psm1984

Si un paquete instalado del sistema depende de una librería y este la borra... no dice mucho a su favor ¿no?. Podreís decir que es una nueva versión... pero... ¿para qué existen los slots?

¿En una binaria solo tiene solución una reinstalación? quizá con tener también las dos librerías mientras tenga dependecia sirva  ¿no?

Saludos.

----------

## Cereza

En una distribución binaria es simplemente infernal trabajar con versiones de los paquetes, la actualización (o desactualización) de un paquete que enlace a muchas (o no tantas) cosas rompe como ya dije, toda una telaraña de dependencias y al menos hasta dondo yo alcanzo a  saber, no puedes tener dos versiones distintas instaladas a la vez. La solución es esperar a una nueva versión de la distribución.

Hace unos meses probé OpenSuse 10.2, intentando hacer andar el software de mi módem, hecho por movistar (...), una porquería de programa que solo "funciona" bajo Suse o Fedora. Para más gloria del software de movistar, era incompatible con la versión de Python que OpenSuse 10.2 lleva de serie (está muy atado a una versión concreta de Python). Intenté desactualizarla (no recuerdo ahora la versión de Python que necesitaba, solo que era anterior a la de OpenSuse 10.2, pero tampoco viene a cuento), el caso es que fue sencillamente imposible, una cosa tan sencilla como bajar de versión, algo que en Gentoo podemos hacer facilmente, no era posible sin necesitar cambiar tropecientas versiones de otros paquetes, que a su vez hacian que otros tropecitos paquetes tuvieran que cambiar de versión y que a su vez  bla bla, una telaraña como ya lo he llamado. Al final la única solución fue instalar OpenSuse 10.1. Ahora el programa ya arrancaba, aunque tampoco conseguí que reconociera el módem, pero eso ya es otra maravillosa historia. Afortunadamente pude acabar conectando en cualquier distro vía wvdial y trasteos en el kernel (alternativa no contemplada por movistar) pero esto también es otra maravillosa historia que no viene a cuento ninguno.

----------

## psm1984

En debian por ejemplo:

 *Quote:*   

> 
> 
> ii  python2.3                        2.3.5-16                    An interactive high-level object-oriented language (version 2.3)
> 
> ii  python2.4                        2.4.4-5                     An interactive high-level object-oriented language (version 2.4)
> ...

 

o dos librerias con versiones distintas...

 *Quote:*   

> 
> 
> ii  libxml1                          1:1.8.17-14                 GNOME XML library
> 
> ii  libxml2                          2.6.29.dfsg-1               GNOME XML library
> ...

 

----------

## i92guboj

 *psm1984 wrote:*   

> Si un paquete instalado del sistema depende de una librería y este la borra... no dice mucho a su favor ¿no?. Podreís decir que es una nueva versión... pero... ¿para qué existen los slots?
> 
> ¿En una binaria solo tiene solución una reinstalación? quizá con tener también las dos librerías mientras tenga dependecia sirva  ¿no?
> 
> Saludos.

 

Los slots no sirven para eso. Además, esto ha sido también discutido en las listas y en bugzilla. Expat no se puede mantener en slots porque sería mucho más problemático. Lost slots no están para eso. Los slots están para versiones distintas de algo que no es compatible a nivel de código fuente. Por ejemplo, es imposible instalar kde3 usando qt4, por eso qt va en un slot aparte, porque ambas versiones son imcompatibles a nivel de fuentes, no a nivel binario.

Por contra, todos los paquetes que se compilaban con el viejo expat se pueden compilar contra el nuevo.

Si hacemos caso de tu argumento, entonces revdep-rebuild on sirve para nada. Simplemente, instalemos 50 versiones de todos los paquetes y así no tendremos problemas. ¿No es algo absurdo?

El ejemplo que pones arriba de debian lo tienes también en Gentoo. Es simplemente que los slots están para un fin determinado, que no es este caso.

----------

## psm1984

 *i92guboj wrote:*   

> 
> 
> Si hacemos caso de tu argumento, entonces revdep-rebuild on sirve para nada. Simplemente, instalemos 50 versiones de todos los paquetes y así no tendremos problemas. ¿No es algo absurdo?
> 
> 

 

 *man revdep-rebuild wrote:*   

> 
> 
> revdep-rebuild  scans  libraries and binaries for missing shared library dependencies and fixes them 
> 
> 

 

Si no se rompe nada, pues no, no sirve de nada. No, no son 50 versiones de todo, no hay que exagerar, son poco comunes los cambios tan fuertes en librerias. Solo digo mantenerlos mientras queden programas que dependan de esas librerias. ¿No es más absurdo borrarte un fichero al que 100 programas que acabas de compilar han linkado sobre él? Vale, puede ser que los slots no sirvan para ese caso concreto, puede que haya razones de peso que no contemple, pero desde mi punto de vista de usuario no lo veo como la mejor opción. Lo único que he leido de slots es:

 *http://www.gentoo.org/doc/es/handbook/handbook-x86.xml?part=2&chap=1 wrote:*   

> 
> 
> Con Portage diferentes versiones de un mismo paquete pueden coexistir en un sistema. Mientras otras distribuciones tienden a renombrar el paquete con sus versiones (por ejemplo freetype and freetype2). Portage usa una tecnología llamada SLOTs (ranuras). Un ebuild declara un cierto SLOT para su versión. Ebuilds con diferentes SLOTs pueden coexistir en el mismo sistema. Por ejemplo, el paquete freetype tiene ebuilds con SLOT="1" y SLOT="2".
> 
> 

 

 *i92guboj wrote:*   

> 
> 
> El ejemplo que pones arriba de debian lo tienes también en Gentoo. Es simplemente que los slots están para un fin determinado, que no es este caso.
> 
> 

 

Lo se (y mejor hecho porque no son nombres de paquetes distintos como en debian), simplemente quería decir que no es sólo gentoo la que tiene esa opción.

----------

## i92guboj

 *psm1984 wrote:*   

>  *i92guboj wrote:*   
> 
> Si hacemos caso de tu argumento, entonces revdep-rebuild on sirve para nada. Simplemente, instalemos 50 versiones de todos los paquetes y así no tendremos problemas. ¿No es algo absurdo?
> 
>  
> ...

 

Este no es el mismo caso. Los programas que dices, no dependen de dicha librería, andarán igual de bien con la nueva versión. Solo requieren ser recompilados. Si no quieres recompilarlos, enmascara la nueva versión. La gente se queja de la velocidad de portage. ¿Sabes cuanto más disminuiría dicha velocidad si nos dedicamos a comprobar la info de ldd para todos los binarios de sistema cada vez que se instale un paquete? Exactamente lo mismo que tarda un revdep-rebuild en hacerse. ¿De verdad insinúas que si se produce dicha penalización en la velocidad no te quejarías?

Yo creo que esto es una causa perdida jeje, porque todo no puede ser perfecto. Los cambios en las librerías son frecuentes, todo depende de las que tú tengas instaladas, es imposible hacer feliz a todo el mundo. Cambios así en python, libxml y similares siempre traen asociados una catarata de posts de similar naturaleza, que nunca llevan a ningún lado.

Personalmente, me niego a tener un infierno similar al que se ha organizado en portage con automake, del que se necesitan 5 o 6 versiones instaladas en slots (y en este caso si es necesario, porque son incompatibles). En el caso de expat hay una solución mucho más fácil: recompilar.

----------

## sefirotsama

Menudo pollo he montado... La única queja que quiero dejar de cara al futuro, como definitiva al tema, es que se deberia ejecutar automáticamente al final de la actualización de libreria expat revdep-rebuild -X --library libexpat.so.0. Es absurdo que NO se ejecute y luego te manden besos por escrito diciendote que lo hagas tu en persona ya que tu sistema se ha quedado hecho trizas.

De todas maneras mi caso así se queda... ahora estoy, durante el dia bajando paquetes (nunca acabo) y por la noche (me toca hacer un turno nocturo estos dias) en el trabajo dejo el ordenador compilando desde el chroot en ubuntu. Pero por muy fetch only que haga siempre se le olvida (o al portage, o a mi) algún paquete necesario para proseguir con la instalación. Al final conseguiré un nuevo gentoo puro y limpio... (la ultima vez fui con prisas y pasa lo que pasa).

En todo caso, cambio el titulo a Gentoo con el culo al aire (aparcado) ya que mi caso no tiene solución y si la hubiera... seria demasiado tarde.

----------

## opotonil

Normalmente seria logico que se hiciera revdep-rebuild -X --library libexpat.so.0 automaticamente, pero en este caso pasaron a estable al mismo tiempo expat, kde y gnome de manera que si no me equivoco si se hiciera automaticamente el revdep-rebuild despues de la actualizacion de expat se recompilaria gran parte de la version actual de kde o gnome que se este usando y una vez terminado se compilaria la nueva version de kde o gnome, para terminar con la actualizacion del sistema, lo que serian muchas horas de compìlacion...

En resumen, si se hiciera automaticamente el revdep-rebuild de expat la mayor parte de la gente compilaria 2 veces kde o gnome ya que son los escritorios mas ampliamente utilizados.

Salu2.

----------

## Franchute13

Hola perinola.

Mi solucion fue un poco drastica, pero funciona  :Smile: 

Primero

un 

emerge --prune

luego 

emerge -evD world

luego

revdep-rebuild el cual se quejo que no podia emergear algunos paquetes, entonces agarre esos paquetes y

emerge unmerge "esos paquetes"

luego nuevamente el revdep-rebuild

y listo.

Claro que demoro lindo tiempo todo esto y es una solucion super bestial, pero solucion al fin.

Saludos

----------

## zorth

hola.

yo si veo los avisos de portage... aun uso ese script tan majo: enotice  :Smile:  y aun asi, me he comido el marron de expat con la boca llena. ahora, resulta que nada funciona si no creo ese famoso enlace simbolico a libexpat.so.0 y tras hacer varias veces revdep-rebuild -X --library libexpat.so.0, siempre me acaba fallando la compilacion en qt-3. 

mi solucion va a ser la misma drastica del compañero de arriba por lo que veo:

```

Total: 522 packages (50 upgrades, 1 downgrade, 2 new, 1 in new slot, 468 reinstalls, 1 block), Size of downloads: 1,129,052 kB

```

un emerge -ev world y a cascarla...

espero que no me falle tambien ahora   :Confused: 

este marron me recuerda al que me comi la ultima vez cuando se acabo /dev para pasar a /udev xD... cosas de la vida y de no usar windows xP.

saludos.

----------

## chumi

Igual estoy equivocado, pero me parece que al realizar revdep-rebuild con la opción '-X' no se reemergen correctamente los paquetes con slots, como qt (siempre se actualiza la última versión, no las anteriores). En mi caso, despues del revdep-rebuild -X realicé otro revdep-rebuild sin parámteros, e incluso al final creo que apunté los paquetes que aún fallaban y los actualicé a mano especificando el slot que fallaba.

Saludos!!

----------

## zorth

asi es. actualiza a la version x11-libs/qt-3.3.8-r3 en mi caso la cual falla una y otra vez. da igual si la emergo con revdep-rebuild o a mano por separado. he probado los paquetes que fallan al compilar en distinto orden y siguen haciendolo... hare un emerge -e con el simlink borrado de libexpat.so.0 esta noche y a ver si suenan las campanas por la mañana y esta todo recompilado.

saludos.

----------

## Noss

 *zorth wrote:*   

> asi es. actualiza a la version x11-libs/qt-3.3.8-r3 en mi caso la cual falla una y otra vez. da igual si la emergo con revdep-rebuild o a mano por separado. he probado los paquetes que fallan al compilar en distinto orden y siguen haciendolo... hare un emerge -e con el simlink borrado de libexpat.so.0 esta noche y a ver si suenan las campanas por la mañana y esta todo recompilado.
> 
> saludos.

 

Joder otro que ha caido... es cierto que esto es inaceptable... menuda putada.... A mi me falla tambien el qt-3.3.8-r3... si das con la solución por favor posteala porque no puedo ni arrancar las X.... menudo fiasco...

Si se emerge todo el sistema se termina solucionando ?

un saludo

----------

## pcmaster

Yo no uso kde ni gnome, uso xfce4 pero tengo instaladas las liberías gtk+ y qt por neecsidades de otros programas.

Como explico en mi primer mensaje en este hilo (página 1) lo solucioné recompilando TODO, aunque algunos paquetes fallaron y, tras hacer cada vez el emerge --resume, al final los recompilé de nuevo y entonces ya no fallaron.

----------

## Noss

 *pcmaster wrote:*   

> Yo no uso kde ni gnome, uso xfce4 pero tengo instaladas las liberías gtk+ y qt por neecsidades de otros programas.
> 
> Como explico en mi primer mensaje en este hilo (página 1) lo solucioné recompilando TODO, aunque algunos paquetes fallaron y, tras hacer cada vez el emerge --resume, al final los recompilé de nuevo y entonces ya no fallaron.

 

Ya.. lo intenté pero me falla nada más empezar la compilación al 5 paquete o así... y cuando vuelvo a intentarlo igual

Al final he hecho algo parecido a lo que ha dicho Howllet revdep-rebuild -X --library libexpat.so y aunque ha petado a mitad de los 27 paquetes que tenía que emerger... parece que me está dejando hacer un emerge -uDv world ... a ver si así está solucionado ya contaré

----------

## pcmaster

Cuando falla un paquete, haces un emerge --resume --skipfirst, para que continúe con el siguiente paquete.

----------

## sefirotsama

 *pcmaster wrote:*   

> Cuando falla un paquete, haces un emerge --resume --skipfirst, para que continúe con el siguiente paquete.

 

No conocia esta opción de portage... me hubiera facilitado la vida...

----------

## Noss

 *sefirotsama wrote:*   

>  *pcmaster wrote:*   Cuando falla un paquete, haces un emerge --resume --skipfirst, para que continúe con el siguiente paquete. 
> 
> No conocia esta opción de portage... me hubiera facilitado la vida...

 

Pero al final resolvites el problema?, cómo?. Yo lo estoy haciedo como nos han aconsejado con el --skipfirst pero es en un portátil y creo que me va a llevar TODA la noche.. así que paciencia... si al final todo vuelve a funcionar me doy por satisfecho

un saludo y me alegro de que sigas en gentoo, eso creo, que sigues.. eso espero

----------

## sefirotsama

He hecho una instalación nueva conservando etc y home y algo más.

Si en gentoo con le alma en gentoo y chroot a través de ubuntu... me queda hacer unos detallitos del arranque y del kernel para volver a resucitar la mallor partición de mi disco duro....

He aprovechado la ocasión para rehacer el sistema entero de manera limpia... no se le puede llamar solución, pero estoy aprovechando el tiempo libre que me queda para pulir ese gentoo que tanto quiero. Y cuando lo rearranque hare lo imprescindible (preparar qemu para arrancar un XP por si lo necesito para algo de la uni y algún detallito más).

Ya contaré mejor en otro momento

----------

## kabutor

pues la de libexpat no ha sido para tanto, la anterior que habia q recompilar todo el sistema dos veces sique fue buena   :Laughing: 

----------

## Ark del KAOS

Ciertamente; a mi con un par de miseros revdep-rebuild -X --library libexpat.so.0, y sus correspondientes emerge --resume --skipfirst, se me quedó el sistema perfectamente.

No se si aún habrá alguna dependencia remolona...pero no afecta en nada.

Lo malo de estas cosas es que se pongan cerriles. Esta vez he tenido suerte ^   ^

----------

## sefirotsama

Me ha vuelto a pasar!!!!!!!!!!

Con una instalación nueva...!!!!

Y el foro estaba en read-only (xDD), por lo que he consultado varios hilos de por ahí, y algunos similares, en google y demás...

https://forums.gentoo.org/viewtopic-t-576749-highlight-fontconfig.html

https://forums.gentoo.org/viewtopic-t-579377-highlight-fontconfig.html

El caso es que me aparece un carro enorme de paquetes rotos y comienza, falla reintento con el --skipfirst y nada...

He intentado hacerlo de mil maneras... he emergido primero todo lo que no pertenecia a kde-base y he podido.

Me encuentro que XML-Parser compila bien, fontconfig NO compila (?), y pando NO compila porqué me dice necesitar la libexpat durante la compilación. ¿¿Y ahora que hago???

Excepto hacer un symlink lo he probado todo, y por lo que he leido en esos foros a la gente le ha ido bien haciendo algo así como:

```
$ emerge expat

emerge -1 gettext curl libperl perl

revdep-rebuild -X --library libexpat.so.0

revdep-rebuild -X --library libcurl.so.3

emerge -1 fontconfig cairo pango gtk+ 
```

Incluso les ha funcionado. con esto:

```
emerge --oneshot fontconfig pango &&revdep-rebuild -X --library libexpat.so.0
```

Pero a mi no... necesito ayuda   :Crying or Very sad: 

Me estoy planteando hacer emerge -eD world (780 paquetitos...) y supongo que cerca de 15 horas (ó 50 horas, pq ya no se ni a que paso va el tiempo)

Se aceptan sugerencias (he llegado a restaurar el sistema para volver a caer en lo mismo que me dejó con el culo al aire).

----------

## Tirion

La verdad es que lo tuyo empieza a ser preocupante... a mi el libexpat lo unico asi mas visible que me jodio fue la conexion a internet....(y las X creo que tb...XD), pero vamos, que para recuperar el sistema le hice un link simbolico, y a partir de hay, una vez tenia el sistema funcionando (con la ñapa), borre el link simbolico, revdep-rebuild y a vivir.......

Prueba el link simbolico y el revdep-rebuild

----------

## sefirotsama

El link me lo desaconsejaron muchas veces... tantas que no quise hacerlo... y el revdep se paraba y habia paquetes que fallaban al emerger por esa misma dependencia.... por paquetes sueltos pues eso, conseguí emerger algunos pero siempre llegaba a un punto muerto.

Pero he encontrado la solución (ya tardaba):

time emerge -De world

Que resultaron ser 800 paquetes.... No lo hice entero porqué también me emergió unas nuevas fuentes de kernel y más tarde paró cuando un programa requeria un .config valido (y tonto de mi no me acordé de emerge --resume). Pero ya me sirvió para seguir haciendo. Mi siguiente paso fué:

time emerge -De XML-Parser pango fontconfig

Si no me equivoco esos eran los paquetes clave... y recompilé más de 300 paquetes (ó 200 tal vez). Vaya que esta noche no he pegado ojo... luego el qt el glib el glibc vinieron solos y por ultimo todavio estoy en el revdep-rebuild que le deben faltar pocas horas para acabar.

Sigo pensando que se habria de hacer algo para evitar esta situación, no me refiero al cambio de expat, sinó a que el revdep no solucione nada y tener que recurrir al emerge -De world (emerge todos los paquetes del sistema, tanto instalados como no, del primero al ultimo).

En todo caso me acerco a la luz al final del tunel...

Gracias a todos aquellos que me prestaron ayuda

----------

## pacho2

Si alguien sigue teniendo algún problema con la actualización de libexpat y aún le queda algún paquete por actualizar, que ponga aquí el mensaje de error que le da para intentar ayudarle

Saludos

PD: Yo he actualizado 3 máquinas con gentoo sin ningún problema con el libexpat

----------

## sefirotsama

Iva a decir algo parecido.. por mi parte ya se puede dejar por cerrado.

Si en unos dias nadie se queja de ese tema se podria considerar como cerrado y cambiaria el titulo a "solucionado"...

----------

