bastian escribió:Lo del procesador era por tomarte el pelo, ya te había entendido.
La verdad es que no me he explicado muy bien. Lo otro me refería a que, (creo que) de alguna de las dependencias ya tengo instaladas la versión estable de ese paquete, y no quiero que me la actualice a la versión inestable, porque las aplicaciones que no la necesitan mejor que usen la estable. Así que la pregunta es si puedo tener dos versiones del mismo paquete (la estable y la inestable) instaladas a la vez y si es así como.
Un saludo.
Pero no es la idea de los slots
Fox escribió:
No me has entendido bien. Todas las libreras *-sharp exceptuando dos o tres como gtksourceview y gecko-sharp. puedes tener la version estable (1.0.10) y la version inestable (2.4.0) a la vez instaladas, ya que usan SLOTS.
Asi que tengo dos versiones de gtk-sharp, de glade sharp, etc.
Un saludo.
Ok, cenkiu por toda la aclaración. Ya suponía que editando se podía, y total, es una línea del ebuild, así que si me interesa tampoco es mucho trabajo. Aunque si son varios paquetes los que se quieren tener.Ferdy escribió:SI editas el ebuild... nadie te lo prohibe Pero no es la idea de los slots
.
Mmm... es que recordaba, del manual de ebuilds de cianaramn que me pasaste, que el slot se definía en una de las líneas próximas a la cabecera. Pero claro... no había pensado en todo lo demás... jeje!Ferdy escribió:Ojo que no es solo cambiar una línea. Tienes que hacer que las distintas versiones de los paquetes no instalen ficheros comunes y si es una librería debes asegurarte de que los programas que enlacen con ella puedan elegir qué version utilizar. No es algo tan sencillo como podrás ver si te pones a hacerlo
Hombre, está claro que ténicamente ahora mismo no, pero en cuanto a idea de que se pudiera controlar qué instalar y donde, estaría bien. El problema es cómo hacerlo sencillo.Ferdy escribió:No tiene sentido dejar a los usuarios que decidan sobre qué paquetes van a qué SLOTs por lo que he explicado arriba.
No sé si me has entendido, ó igual sí... Pero vamos, que yo sólo me refería a que hubiera un parámetro de emerge, que hiciera que todas las dependencias que pudiera necesitar un paquete, te las metiera directamente en /etc/portage/package.keywords . Es que ésas cosas son muy cómodas cuando, por ejemplo, sale un Gnome ó un KDE y no se quiere eperar a que pase a "stable".Ferdy escribió:Y sobre el ACCEPT_KEYWORDS, yo prefiero que las cosas se queden como están
.
No sé si me has entendido, ó igual sí... Pero vamos, que yo sólo me refería a que hubiera un parámetro de emerge, que hiciera que todas las dependencias que pudiera necesitar un paquete, te las metiera directamente en /etc/portage/package.keywords . Es que ésas cosas son muy cómodas cuando, por ejemplo, sale un Gnome ó un KDE y no se quiere eperar a que pase a "stable".
Jajaja! Ya hombre, yo sé que tú te lías con tus "push" y estas cosas cosas avanzadas, pero desde el punto de vista de los novatos/torpes... nos vendría muy bienFerdy escribió:Ahora te he entendido. Básicamente no creo que eso fuera una buena idea; yo no lo usaría
.
![[sati]](/images/smilies/nuevos2/demonio.gif "demoniaco")
FuckingFreaky escribió:Lo que te saca lo metes en .keywords ó .unmask y yata. Aunque también se podría hacer que lo hiciera él solo.
.
![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
[/disclaimer] Paloseco escribió:Gracias a Dios ya se acerca el GNU Classpath
GNU Classpath 1.0 will be fully compatible with the 1.1 and largely compliant with the 1.2 API specification and will have a stable API for interacting with virtual machines.
