Author Topic: Problem with RPM packages - conflicting reqs. for libicu  (Read 5225 times)

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Problem with RPM packages - conflicting reqs. for libicu
« on: March 08, 2017, 07:24:25 am »
Hi,

Apache Office 4.1 needs libicu in Version 4.2 (it is looking for DLL icuuc42.dll).
However Firefox needs libicu in Version 56.1 (it is looking for DLL icudt.dll I seem to remember).
The problem is: if I install the newer version, the older version is removed. I had to manually zip all files from the old version package, install the new one and then unzip the saved DLLs.

What is the correct way to deal with this ? Do I need to copy over that old stuff into the Apache Office application directory ?
I admit that I am lost.

Lars

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: Problem with RPM packages - conflicting reqs. for libicu
« Reply #1 on: March 08, 2017, 08:41:21 am »
You need to install libicu-legacy. Legacy packages are the usual way of solving these types of conflicts. Helps to use ANPM so you can see the available packages.
« Last Edit: March 08, 2017, 08:43:14 am by Dave Yeo »

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: Problem with RPM packages - conflicting reqs. for libicu
« Reply #2 on: March 08, 2017, 06:45:55 pm »
You need to install libicu-legacy. Legacy packages are the usual way of solving these types of conflicts. Helps to use ANPM so you can see the available packages.

The actual problem is that AOO doesn't call for libicu-legacy, and it should call for it.

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: Problem with RPM packages - conflicting reqs. for libicu
« Reply #3 on: March 09, 2017, 09:11:35 am »
Yes, that's the problem. After I did the initial posting I realized that the -legacy packages are the ones to install in addition.
Unfortunately this is not explained anywhere. I screwed up my complete system and did a reinstall of YUM/RPM and ANPM from scratch which was painful.

I still think it's a bad idea to put version info into DLL names.

Next question: sometimes there are up to 3 packages for the same thing: a "i386" variant, a "i686" variant and a "pentium4" variant.
Which one to choose ? I have the latest and greatest CPU (AMD CPU with SSE, SSE2, bla bla bla).
In particular I cannot tell the difference between "i686" and "pentium4" and also I don't see what happens if I mix variants between 2 different packages (install one package as "i686" variant and the other as "pentium" variant).

Is there an easy explanation what qualifies as "i686" or "pentium4" ? I am thinking about needed instruction extensions (SSE, AVX, etc. etc.).


Lars


Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: Problem with RPM packages - conflicting reqs. for libicu
« Reply #4 on: March 09, 2017, 09:48:53 am »
i386 is the worst choice and has been depreciated. The big differences between i686 and pentium4 (netburst) is that they use quite different instruction ordering. Really unless you actually have a netburst processor, I think i686 is the best choice. Netburst does support MMX and SSE (only the newest supported SSE2) but not much really uses them, and the stuff where it is important, multimedia apps and even the Mozilla JS engine will probe your CPU and use whatever it is capable of, often with hand written assembly.  Be good to have an architecture that uses SSE2 as SSE2 can replace the floating point coprocessor overhead and is fast at fp math.
In theory it should not matter at all if you mix architectures unless you actually have a i486, in practice RPM seems to treat them as incompatible architectures and doesn't like mixing them. There is a plugin to change a packages architecture if needed.
For your AMD, I'd advise just using i686.

ak120

  • Guest
Re: Problem with RPM packages - conflicting reqs. for libicu
« Reply #5 on: March 09, 2017, 12:53:41 pm »
Yes, that's the problem. After I did the initial posting I realized that the -legacy packages are the ones to install in addition.
Unfortunately this is not explained anywhere. I screwed up my complete system and did a reinstall of YUM/RPM and ANPM from scratch which was painful.
Perhaps the packagers have no clue about RPM functionality to avoid this issues. While evils call OS/2 a half OS, you can think of this RPM as a semiquaver.

Quote
I still think it's a bad idea to put version info into DLL names.
I fully agree. It will introduce more conflicts in future than it aims to resolve by doing it this way.

Quote
Next question: sometimes there are up to 3 packages for the same thing: a "i386" variant, a "i686" variant and a "pentium4" variant.
Here it becomes complicated for the end user. But also for developer's which don't know the innards of GCC code generation or check at least the assembly output. More or less it reflects only the used optimisation switch options of gcc. As the used unofficial GCC port for OS/2 lacks any documentation it's a weird situation. So you have to check the output of gcc -s against your microprocessor manual.
Pentium Pro should be enough for i686, but some instruction which are not mandatory will be generated by gcc. So be careful with embedded CPUs from other vendors.
Pentium 4 usage of SSE was already mentioned by Dave. I will not judge over quality of generated code here.