When upgrading from Mageia 1 to Cauldron, I have this error : Installation failed: file /usr/lib64/libvdemgmt.so.0.0.1 from install of lib64vde3-2.3.2-2.mga2.x86_64 conflicts with file from package lib64vde2-2.2.2-5.1.mga1.x86_64 file /usr/lib64/libvdesnmp.so.0.0.1 from install of lib64vde3-2.3.2-2.mga2.x86_64 conflicts with file from package lib64vde2-2.2.2-5.1.mga1.x86_64 So I think some obsoletes are missing in lib64vde3, or the package should be split with one package for each library.
Blocks: (none) => 3342
Should be fixed in latest vde, I've splitted the libs.
Status: NEW => RESOLVEDCC: (none) => fundawangResolution: (none) => FIXED
Splitting lib for splitting doesn't make sense. I will revert and add obsoletes.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
It's not splitting for splitting, it's splitting for fixing upgrade problems with libs with different major. And that's also what is said in policy : https://wiki.mageia.org/en/Libraries_policy#Special_cases "It is not necessary to split each library in separate packages: if a package contains several libraries, the name would be built from the main library of the package. If there are problems keeping libraries in the same package (e.g. their major may differ), the package should be split."
The previous commit was done without looking at the inter packages requires. All packages using libvde have a requires on libvdeplug.so.3, so installing qemu would just pull 1 library and not the 3 others one, that's too late in the mageia 2 release cycle to do proper testing for such a change on qemu, xen. Also, splitting add small overhead on various levels of the dependency resolution : - it add more headers in hdlist - it add one item in the structure that need to be looped over by urpmi ( looped for looking for provides, but also looped as a package that need to have his dependency fullfilled ). And if the goal is to split library and then have 1 single rpm that requires everything else, it will just add overhead to the system without any notable changes, except added complexity. Hence I prefer the Obsoletes solution, because that's the safest fix and the one who add less problem.
Should be fixed in latest vde2 already
Status: REOPENED => RESOLVEDResolution: (none) => FIXED