Hello, I have an interesting observation: Several Repos activated. Let's call them Repo1 and Repo2. Repo1 provides: pkgA-0.1-1 Repo2 provides pkgA-0.2-1 libpkgA0-0.2-1 (libpkgA was split out from pkgA with the new version, according to the SO-Policy) pkgB-1.0-1 pkgB requires a Shared library, only by the symbol (so no forced Requires:). The symbol is provided by libpgkA0-0.2-1 and also by pkgA-0.1-1. So far, I think every thing is clear (hopefully also clearly illustrated). Now the thing (using zypper): zypper shell zypper> in pkgA it install pkgA-0.2-1 and also libpkgA0-0.2-1 (because one of the binaries within pkgA requires the lib) so: this is exactly as I would say it should be. pkgA-0.2 being newer than 0.1 get's precedence and is thus selected. Now let's 'uninstall' them from the system (no matter how, zypper rpm... just get back to clean state ;) ) zypper shell zypper> in pkgB in this case, zypper resolves the dependencies and offers to install pkgA-0.1-1 Why doesn't it suggest now also to install pkgA-0.2-1 together with libpkgA0-0.2-1? Wouldn't that case be the logical one? a consecutive lu -t package shows that pkgA is 'upgradeable' and a in pkgA pulls it, together with libpkgA0 in... Interesting case for any of the solver hackers around? Or do you think such a case should be 'caught' by the RPM builder, with a Obsoletes: pkgA < 0.2 in the libpkgA0 package? (would be possible I guess, but having a newer pkgA makes it look a bit weird) Dominique -- Sorry for the annoying disclaimer coming now. TMF is a global management and accounting outsourcing firm with 77 offices in 60 countries and over 2,500 professionals (2007). TMF is expanding rapidly throughout the world. Learn more about our unique network and our services and visit our website at www.tmf-group.com. The information contained in this e-mail communication is confidential and solely intended for the person to whom it is addressed. If someone other than the intended recipient should receive or come into possession of this e-mail communication, he/she will not be entitled to read, disseminate, disclose or duplicate it. If you are not the intended recipient, you are requested to notify the sender and to destroy the original e-mail communication. TMF is neither liable for the correct and complete transmission of the information contained in this e-mail communication nor for any delay in its receipt. This footnote also confirms that this email message has been checked for the presence of computer viruses. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org