Re: Uso de talternatives
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
Reply to: