Hi,

If a package changes name the packager should tell rpm (and by extension zypper) about it by using a tag such as obsoletes:

In your case, the package was called -unstable which probably means it was intended to be installed in parallel with the normal one

If there is a bug here, it is that zypper installed the new package with --force, which IMHO is wrong, it shouldn't just overwrite files, it should refuse to install the new package until the collisions have been removed

zypper (and YaST2, even long before zypp existed) has always worked that way: It doesn't install packages in a single transaction, but one by one and therefore *must* use --force (or, more precisely, --replacefiles, which is implied by --force) because otherwise, it wouldn't be able to handle the case where a file is moved from one package to another. The only way to avoid --force (or --replacefiles) is to change zypp so that it installs packages in a single rpm transaction. I *suspect* that there must be a very good reason for not doing so because the solution is just so obvious. The conclusion is that packagers must take extra care to add "Conflicts" tags to their packages if there is indeed a conflict (note that the "Conflicts" does not, despite its ill fame, introduce any conflicts; if used correctly, it just makes the package manager aware of them). A "Conflicts" can later become an "Obsoletes" once there are no conflicts anymore (e.g. after all conflicting packages except one have been dropped). It seems that this was not done in this case. Andreas -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi,

# grep xorg-x11-libxcb-devel /var/log/zypper.log # It didn't throw up any conflicts.

that's exactly the problem. It would have if the packages had correct dependencies. As a rule of thumb, it's a good idea to stay away from packages whose name is the name of another package plus the word "unstable". Not because of the software inside, but because a clean upgrade path (packagename -> packagename-unstable -> packagename) requires rather complex and well-thought-of dependencies with versioned Conflicts/Obsoletes tags that most packagers don't do. For packagers who feel a need to add the word "unstable", it is much easier to put this into the version number or into the name of the repository. Andreas -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

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. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org