A Dimarts 22 Abril 2008, Adeodato Simó va escriure: > * Leopold Palomo Avellaneda [Sun, 20 Apr 2008 12:42:26 +0200]: > > alguien sabe si hay algún problema en utilizar las debian-alternatives > > para una biblioteca? > > > > Por ejemplo, tengo libfoo y quiero tener dos versiones libfooa y libfoob. > > Por defecto los programas linkan contra libfoo. Pero, upstream tiene una > > migración de libfoo(características a) hacia libfoo(características b). > > > > Tenia pensado poner libfooa y libfoob y por el uso de alternatives un > > enlace de libfoo a libfooa o libfoob. En mi máquina funciona pero he > > visto que si puede ser problemático y tampoco he visto nada en contra en > > las "policies". > > > > Alguna idea? comentario? > > A ver, está bastante claro que las alternatives sólo se pueden usar > cuando las alternativas son muy o bastantes compatibles.
o contrarias > El caso de usar alternatives para una biblioteca, de entrada, me huele > un poco: sólo se podría hacer si *cualquier* binario linkado con libfoo > funciona correctamente tanto contra libfooA como libfooB. Lo cual suele > significar que tanto A como B deberán tener exactamente los mismos > símbolos públicos, ¿es ese el caso? Nops. EL caso es para la biblioteca soqt. Es una biblioteca que que tiene como dependencias coin3d (biblioteca de gràficos) y qt (para poner un widgets y ventanaa). Actualmente upstream soporta que esta biblioteca se compile con qt3 o qt4. Evidentemente son incompatibles, pero a nivel de código y de includes son compatibles a nivel de compilación. No cambias absolutamente nada y compilas y linkas contra uno o el otro. El paquete debian sólo tiene una versión. Tengo un wishlist pero el maintainer no le ha hecho mucho caso. :( Por suerte, esto ha cambiado un poco y con el maintaner se está poniendo las pilas en esto (no le puedo culpar, lleva mogollón de paquetes ...) . El parche que le he enviado y tiene estudiando utiliza alternatives para proporcionar una versión por defecto. Un poco como lo hacen con moc y uic en qt. Creo que petsc lo hace con una biblioteca. La idea funciona y lo que quería era asegurarme si había alguna cosa respecto a eso. Evidentemente que no son compatibles, pero permitiría poder tener una versión por defecto y a medida que pase el tiempo y la versión de qt3 sea antigua ir la substituyendo por qt4. Por suerte no hay ningún paquete (por ahora ...) que lo utilice. libSoQt.so.20 apunta a un libSoQt3.so.20 o a libSoQt4.so.20 dependiendo de que versión quieras por defecto. Igual que las versión de desarrollo también puedes linkar contra libSoQt3 o libSoQt4. Con este planteamiento, la biblioteca en debian se llama "diferente" (tiene el sufijo 3 o 4 dependiendo contra quién) que upstream, pero existe la opción de poner un "por defecto" que apunte a uno u otro. Ea, ya paro, vaya rollo que he metido. Leo
