On 17/02/11 10:09, Dave Plater wrote:
On 12/22/2010 02:19 AM, Sid Boyce wrote:
Building xine-lib-1.1.19 on 11.3 x86_64, I hit this error. /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld:
/usr/lib64/libxcb-shape.a(shape.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/lib64/libxcb-shape.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[3]: *** [xineplug_vo_out_xcbshm.la] Error 1 make[3]: Leaving directory `/ftp/dec10/xine-lib-1.1.19/src/video_out' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/ftp/dec10/xine-lib-1.1.19/src/video_out' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/ftp/dec10/xine-lib-1.1.19/src' make: *** [all-recursive] Error 1
It was a rogue library lying around from 2009 "zypper rm xorg-x11-libxcb-unstable-devel" fixed it.
When zypper upgraded it installed xorg-x11-libxcb-devel and left files from the old one in place. It seems it's not able to detect and deal with a package name that differs but offers largely the same files, so it leaves any file that isn't part of the current package in place. In fact it leaves the old package installed.
I shall open a bug later. Regards Sid. Excuse the really late reply. It's not zypper that determines what replaces what,in this case, it's actually the packager. If a package is renamed or replaced with one that provides the same files rpm needs to know about it so the packager will provide and obsolete it in the spec file. The best way to get a good idea of this is to read : http://en.opensuse.org/openSUSE:Package_naming_guidelines#Renaming.2Freplaci...
or just in case the link is too long : http://en.opensuse.org/openSUSE:Package_naming_guidelines
An example: I used to build the non kde3 dependent qt4 based rosegarden from svn as rosegarden-qt4 in my home project but the binary was still /usr/bin/rosegarden, when it was eventually released as rosegarden4-10.01 I placed in the spec file "Provides: rosegarden-qt4 = %{version}" and "Obsoletes: rosegarden-qt4< %{version}" because a user was testing it and helping to fix bugs and I didn't want any obsolete files left hanging around and provided a clean upgrade path.
It's actually important to understand this from a testing point of view because what you experienced is actually a bug and the packager of xorg-x11-libxcb should maybe have put obsoletes and provides in the spec file. Of course we're not clairvoyant and a spec file with 200 lines of obsoletes/provides is hard to manage so if you install some strange unsupported package you need to make sure it doesn't come back and bite you. Although rpmbuild is responsible for picking up requirements and provisions the human that uses it needs to try to make sure that everything is ok.
Dave P
I rarely do fresh installs - only if a HD dies - and I'd be hard pressed to remember the base level but it's at least 11.1 Milestone 0 or earlier and incrementally upgraded to 11.4 RC1, so it probably is no surprise something makes a mis-step occasionally. There was a stage when zypper/libzypp/satsolver caused problems like automatically installing i586 packages without reporting conflicts though *i586* zypper lock was set. The systems now are pretty much AOK. The reason I prefer upgrades is that I see it as a good test of the robustness of the software ecosystem. It's not let me down ever and is testament to the great job you guys do. Regards Sid. Last clean install I did was 11.2 and it's so much hassle to backup /etc and friends as well as having to change the urls in my many .repo files
On 02/17/2011 01:33 PM, Sid Boyce wrote: that are used for packaging that a zypper dup is the way for me to go. At least I have control over the upgrade path of the packages I maintain and my 11.3 system has files newer than factory at this stage. I must update to 11.4 over the weekend. Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org