@markkp can I please see the bug reports.

Mark Post (markkp) - over 5 years ago

author

They're marked SUSE employees only, so I don't think so. Basically they talk about file conflicts between the old package and the new package during system upgrades. What additional info would you need from them?

---

Jan Engelhardt (jengelh) - over 5 years ago

reviewer

You can just add individuals to Cc on request (such as this). Whatever rpm/zypp put out on the command line would be the important part - I won't really know until I see it.

OK, I've done that. I don't think it will help much with the 1104638 bug. That references an internal SUSE QA system that you won't be able to access. The output from that is very, very similar to what you'll see in 1046435.

12-SP2's libica2 has libica.so.2 and /usr/bin/icainfo. Factory's libica2 (a suitably old version that lies just in between) has just libica.so.2, and there exists a libica-tools already.

That made me think:

%package tools
Provides:  libica2:/usr/bin/icainfo

instead of an Obsoletes.

(as per https://en.opensuse.org/openSUSE:Upgrade_dependencies_explanation#Splitting_off_a_sub-package )

I am not sure if this works in practice, and since the next generation (libica3) is already there, maybe it is not worth trying.

Mark Post (markkp) - over 5 years ago

author

I did try that, but it didn't seem to work. That's when I gave up and used Obsoletes instead, which did work.

Given the convoluted history of this package and it's naming/contents, etc., we really do want libica2 to be removed from the system when libica-tools and libica3 are installed. Running "zypper in libica3" brings in libica-tools and removes libica2, which is the desired effect. (And, "zypper in libica-tools" brings in libica3 and removes libica2.)