Am Samstag, 24. Januar 2009 schrieb Cristian Morales Vega: <snip> > >> Just to remove any doubt: > >> > >> # LC_ALL=C zypper --disable-system-resolvables in -D -r dvd > >> 'libopenal.so.0()(64bit)' > >> Loading repository data... > >> Resolving package dependencies... > >> > >> The following NEW packages are going to be installed: > >> bash bash-doc e2fsprogs filesystem glibc info libblkid1 libbz2-1 > >> libcom_err2 libext2fs2 > >> libncurses5 libopenal0-soft libopenal1-soft libreadline5 libuuid1 > >> libvolume_id1 libzio ncurses-utils openal-soft readline-doc > >> terminfo-base zlib > >> > >> > >> Overall download size: 4.1 M. After the operation, additional 12.4 M > >> will be used. > >> Continue? [YES/no]: n > >> > >> openal-soft is selected instead of openal. > > > > A new package is uploaded as I needed to rebuild it with new ogre-1.6.1. > > For openSuSE-11.1 it is build with openal-soft. > > > > and openal-soft(-devel) is NOT compatible to openal package, so IMHO it > > is totally wrong to provide openal in the openal-soft-devel package. > > > > e.g. ember build is failing with openal-soft ... and so I stay with the > > working openal(-devel) package of the packman repository. > > I will open a bug report since the situation seems funny... > 1- Upstream openal-soft only provides libopenal.so.1, but openSUSE > patched it to also create a wrapper library with soname > libopenal.so.0. If you try hard you can have both original openal and > openal-soft (without wrapper) installed at the same time without any > conflict, but...
> 2- The full repository has available both openal and openal-soft, but > the DVD only provides openal-soft. At the same time zypper will select > openal-soft by default when both options are available. So openal-soft > is the default, true? Well, no... the Build Service has a "Prefer: > -libopenal0-soft -openal-soft" for both 11.1 and Factory, that seems > makes openal prefered over openal-soft. > 3- Because of '2' freealut is compiled against original openal. > 4- openal package provides a libtool .la file but openal-soft doesn't. > Since freealut is compiled against openal "libalut.la" hardcodes a > dependency against a libopenal.la file that doesn't exists in > openal-soft. That's why ember fails to compile (now I also hate > libtool). If you remove the libalut.la file embed compiles correctly > (with the libalut.so.0 from freealut vs direct libalut.so.1 dependecy > conflict that god knows what will do if you use the real libalut.so.0 > instead of the wrapper). well analysed ! As a conclusion: I must check my spec-files to remove "Requires: openal", because this way I can't force the use of the packman package, as the openals-soft package tries to "provide: openal" and contains also a library with the old so-name of original openal... So lets hope that our beloved games are still working with this mess. Your detailed feedback is very appreciated. If things go worse, I can try to link openal statically and or switch to other sound-output possibilities (in case of funguloids: fmod) As we build our packages in a chroot, the removal of libopenal.la is not possible on the fly. One possibility is to repack the package for the packman repo. -- have fun Toni _______________________________________________ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman