Mailinglist Archive: zypp-devel (56 mails)

["Dominique Leuenberger" <Dominique.Leuenberger@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx