Re: [gentoo-user-es] emerge, gimp y gimp2 [SOLVED]

[Manuel Pérez López]

El Jueves 29 Abril 2004 02:00, Marcos Garcia escribió:
> bueno pues haz como te he dicho, un script o un alias para usar el
> emerge con programas inestables...
> pero luego no te extraqe ver si haces un "emerge -u world" cosas raras,
> al mezclar estable (emerge con "x86") con testing (emerge con "~x86")
>
> mira lo que uso:
>  >>> cat /usr/bin/xemerge
>
> #!/bin/bash
> ACCEPT_KEYWORDS="~x86" emerge -v $*
>
> recuerda de hacerle "chmod +x /usr/bin/xemerge"
> y no uses despues de eso emerge -u world, sino emerge -U world...

Acabo de corregir el error. Bueno, parece que el comportamiento de emerge 
depende, como sabéis, de unos ficheritos de configuración que se colocan en 
el /etc/portage/. Todos estamos acostumbrados a toquetear 
el /etc/portage/package.unmask para desenmarscarar ciertos paquetes de la 
rama inestable profunda de Gentoo. Pues bien, emerge (supongo que en alguna 
versión reciente de los últimos meses) también mira su configuración en otro 
ficherito situado en /etc/portage/package.keywords con un contenido muy 
similar al anteriormente referido (mirad abajo el ejemplo que yo realmente 
estoy usando). Este fichero, por lo visto, configura el comportamiento de 
emerge para que determinados paquetes allí colocados se instalen desde la 
rama estable o inestable -según se especifique-, y solo ellos. Lo de sólo 
ellos es muy importante, como ahora explicaré. Si este fichero de 
configuración no existe, emerge falla a la hora de hacer una actualización 
del sistema que tiene paquetes de la rama estable e inestable mezclados. 
Normalmente uno quiere actualizar los paquetes estables con los nuevos 
paquetes también estables, pero esto no se consigue si hay algun paquete de 
la rama ~x86 en el sistema, pretendiendo este hacer un downgrade de los 
mismos. Si intentamos corregirlo con un emerge -U para un paquete específico, 
emerge se comporta bien, siempre que sus dependencias no estén en la rama 
inestable. Si anteponemos un ACCEPT_KEYWORDS=~x86 tendremos el problema de 
que las dependencias que se instalen también serán de la rama inestable, y 
quizás eso no queramos -ni sea deseable-. Lo ideal sería que yo pudiera hacer 
un emerge -pvUD world y que se actualizaran de la rama estable todos mis 
paquetes, excepto los especificados en /etc/portage/package.keywords, y 
solamente estos (no sus dependencias). 


¡Hacía ya mucho tiempo que no hacía un emerge -UD world limpiamente!

Otra cosa, Marcos. Si en Gentoo se mezclan paquetes de la rama estable y de la 
rama inestable no tienes 'la caja de bombas' que tú nos comentas allí arriba. 
Aunque este problema ocurre en cierto grado en Gentoo, es muchisimo más 
estable que las distribuciones que se basan en paquetes precompilados. Me 
estoy refiriendo concretamente a Debian y su problema intrinseco derivado de 
una rama estable muy antigua (yo diría obsoleta) y otra rama menos antigua 
pero inestable. Y te explico porqué: cuando compilamos con Gentoo metemos 
unos flags con USE que no es otra cosa que decirle al configure que queremos 
determinadas caracteristicas de un programa, además de dependencias con otro 
software y otras cosas que no vienen a cuento. Si en la compilación esas 
caracteristicas que le hemos asignado a nuestro paquete no son compatibles 
con nuestro sistema actual, no podemos compilar y aparecen errores. Eso hace 
que no podamos tener un softaware que nuestro sistema no soporta. Los 
usuarios de Debian tienen un problema con esto, y es que sus paquetes vienen 
precompilados y, aunque tienen muy en cuenta las dependencias con otro 
software, pueden meter la pata si no están muy bien construidos, porque el 
sistema que recibe el paquete inestable no es el propicio. Te pongo un 
ejemplo y paro el royo: supogamos que quieres instalar mplayer con soporte 
para control remoto por infrarojos (un mando a distancia controla mplayer); 
en Gentoo, simplemente pones el USE="lirc" y empiezas a compilar, pero si tu 
kernel no ha encontrado el hardware apropiado de infrarojos (y por lo tanto 
no te ha cargado el modulo oportuno) no podrás compilar, y te fallará. En 
Debian, como ya viene compilado, se puede tragar si no ha sido muy listo el 
constructor del paquete, y despues llegan los disgustos para los Debianitas 
por inestabilidad (¡coño! ¡si he instalado el mplayer y no me funciona el 
mando a distancia! o bien ¿que ocurre que cuando aprieto la tecla de play con 
el mando a distancia con el mplayer abierto se me bloquea el sistema?)

Saludos
Manuel Pérez

Mi reciente /etc/portage/package.keywords
>=media-gfx/gimp-2.0.0 ~x86
>=x11-libs/qt-3.3.2 ~x86

>=app-cdr/k3b-0.11.9 ~x86
>=app-editors/quanta-3.2.2 ~x86
>=app-office/koffice-i18n-1.3 ~x86
>=app-office/koffice-1.3 ~x86
>=dev-util/kdevelop-3.0.90 ~x86
>=dev-util/lincvs-1.3.0 ~x86

>=kde-base/kde-3.2.2 ~x86
>=kde-base/kdeaccessibility-3.2.2 ~x86
>=kde-base/kdeaddons-3.2.2 ~x86
>=kde-base/kdeadmin-3.2.2 ~x86
>=kde-base/kdeartwork-3.2.2 ~x86
>=kde-base/kdebase-3.2.2 ~x86
>=kde-base/kdebindings-3.2.2 ~x86
>=kde-base/kdeedu-3.2.2 ~x86
>=kde-base/kdegames-3.2.2 ~x86
>=kde-base/kdegraphics-3.2.2 ~x86
>=kde-base/kde-i18n-3.2.2 ~x86
>=kde-base/kdemultimedia-3.2.2-r1 ~x86
>=kde-base/kdenetwork-3.2.2 ~x86
>=kde-base/kdepim-3.2.2 ~x86
>=kde-base/kdesdk-3.2.2 ~x86
>=kde-base/kdetoys-3.2.2 ~x86
>=kde-base/kdeutils-3.2.2 ~x86
>=kde-base/arts-1.2.2 ~x86
>=kde-base/kdelibs-3.2.2 ~x86



















--
gentoo-user-es@g.o mailing list