Project

General

Profile

Ongoing issues with icu ...

Time4Tea - 14 days ago -

I seem to be having ongoing issues with the icu library package, especially with regards to trying to upgrade software on my system.

Earlier today I tried to install and run octave on my x86 desktop. When I tried to open it, it wouldn't start and the error message in the terminal indicated it was because it wanted the latest version of qt5. So, I upgraded qt5, but it still didn't work, because that wanted a newer icu library. So, I gritted my teeth and upgraded icu from 65 to 67. After doing this, octave now started and seemed to run well. However, on rebooting my system, I suddenly started experiencing issues with the DM (SDDM) and the Mate desktop environment. So, I upgraded all the Mate packages as well as xorg-server and xorg-server-common, for good measure. Nope, I'm still getting the issues with Mate. So, I downgrade icu back to version 65. Mate now runs fine, but obviously octave doesn't work again.

It seems there is a fundamental conflict: the latest versions of octave and qt5 in the repo need icu 67; however, the latest versions of the Mate packages insist on icu 65. I swear, the last 3 times I have tried to upgrade my system, I have run into this same catch-22, where it seems half the packages depend on a newer version of icu and the other half depend on the older version and everything just falls over.

So, this time I created a dummy package of my own, called icu-65, which contains just the library files from version 65 of the icu package. I installed this alongside the newer version 67 and now everything seems to work well - I can have the newer version of octave without Mate falling over.

So, if I could make a request/suggestion: what about re-packaging newer versions of icu so that the package includes the library files for the previous version or two, to maintain compatibility? As far as I can see, the only real solution to the problem here is to have multiple versions of icu installed side-by-side. Furthermore, the way the library files are set up, with the version number included in the filename, seems to indicate there was some intention for multiple versions to be installed on a system, since the library files don't conflict. There has to be a better way of doing this, that can avoid all this breakage?


Replies (6)

Ongoing issues with icu ... - bill-auger - 14 days ago -

all of those problems are caused by partial upgrades (upgrading
only selected package) - that can cause many sorts of problems
- to ensure that the entire system sane, always upgraded
completely with `pacman -Syu`, before installing any new packages

if `pacman -Syu` ever causes an error, that is almost always a
bug - icu v67 replaced v65 about three months ago - the problem
could have been fixed by now, if someone had reported it

there is a 'icu-65-compat' package, which will allow programs
which require icu v65 to be used with the current system - you
did not need to create one yourself - but, 'icu-65-compat' is
only a temporary work-around - if any packages in the parabola
repos require icu v65, they need to be rebuilt

we keep a list of such packages on the bug tracker; but there
are no MATE packages on that list - if you could identify
exactly which packages require icu-65, we should add them to the
list, and get the rebuilt

RE: Ongoing issues with icu ... - Time4Tea - 14 days ago -

bill-auger thanks for your reply.

From my point-of-view, I have become very wary of doing `pacman -Syu`, because I have done it several times in the recent past and each time it has resulted in widespread system breakage. The problem I see with the full upgrade is that, if something serious does break, it can be much harder to pinpoint what caused it, if I have just upgraded 100+ packages. Also, as far as I am aware, there is no feature in pacman to easily roll back a whole system upgrade. So, I have been in a position where I have had to spend many hours checking log files and rolling back individual packages one by one, to try to diagnose system problems.

So, I have been starting to favor doing more 'piecemeal' upgrades, as and when I need a new version of something. The reason I was able to fairly quickly pinpoint the issue and fix my system this time is because I only upgraded a handful of packages. I know I should probably be flagging these sorts of things as bugs and I will try to do so when I can. However, I am going through a particularly busy period atm (4-mo baby).

I wasn't aware of your 'icu-65-compat' package, but I will use that as it will be very helpful.

It seems to me that both full upgrades and partial upgrades should be viable, if the package metadata is correct, because pacman should prevent upgrades that will break things. I.e. if octave requires qt5 version 5.15, then its metadata should say that. If qt5-base requires icu version 67, it should also say that. Looking at it now, it doesn't seem to even have a dependency on 'icu'. I know it's not a perfect world though and maintaining all that metadata is a big task. I will continue to post bug reports when I can, and if I come across any packages that seem to depend on an old icu version, I will flag them.

One other question I have: do you guys keep a list of packages that depend on a specific version of icu? Then, when a new version of icu hits the floor, do you try to rebuild those and release the new icu version and all of the dependent packages simultaneously? It seems that would be necessary to avoid breakage, without having backwards compatibility built into icu.

RE: Ongoing issues with icu ... - bill-auger - 14 days ago -

the plan is to maintain a icu-compat package for each icu version N-1 - that should eliminate any incompatabilities, and it will be uneventful when any icu-dependent package is rebuilt - nothing would be broken until the next icu, which is usually several months in the future, if some package still had not been rebuilt yet

partial upgrades are the largest cause of incompatibilities - QT is especially finicky about the entire system rolling at the same speed - if you hold back packages, then it wont do any good to report bugs - the solution to most of those bugs will be `pacman -Syu` - the only bugs that can be fixed, are one which exist in the current up-to-date system - even those, very often fix themselves, with the next upgrade

the plan you are describing could work perfectly if you do not ever upgrade any packages, and just keep everything exactly how it is, when it is working well - thats essentially what LTS distros do; because it is the best way to minimize incompatibilities and broken programs

if you do not want to use a LTS distro, i suggest that a better plan than what you are doing, is to install two complete systems, one with linux-libre, and one with linux-libre-lts, upgrading them both at least once per month, two weeks apart - even better if they are on separate physical disks; because every disk will stop working someday, and without warning

that is what i do - in practice, i have never needed that arrangement; but i maintain them both anyways, as a back-up plan, just in case - that way you should always have at least one working system, up-to-date, and without any partial upgrades - and any problems you do have, will be current, and can be addressed

RE: Ongoing issues with icu ... - eschwartz - 13 days ago -

It seems to me that both full upgrades and partial upgrades should be viable, if the package metadata is correct, because pacman should prevent upgrades that will break things. I.e. if octave requires qt5 version 5.15, then its metadata should say that. If qt5-base requires icu version 67, it should also say that. Looking at it now, it doesn't seem to even have a dependency on 'icu'. I know it's not a perfect world though and maintaining all that metadata is a big task. I will continue to post bug reports when I can, and if I come across any packages that seem to depend on an old icu version, I will flag them.

Arch Linux deliberately refuses to maintain any such compatibility metadata, on the grounds that only pacman -Syu is supported. It is a tremendous amount of busywork, and while sometimes the use of libfoo.so style autoversioned dependencies can prevent the trivial errors, Qt5 minor version compatibility breakage for any software using private headers is NOT tied to sonames. It also doesn't work for things like python/perl/ruby modules, or anything depending on a command-line interface to subprocessed programs...

Your problem is entirely related to the boundary between Parabola's overlay repos and their imported dependencies from Arch. Parabola needs to rebuild certain [libre] and [pcr] packages with coordinated accuracy down to the minute, in accordance with synced dependencies from Arch; this is not practical, so they try to do so as soon as possible instead.

In the case of ICU specifically, this is a solved problem via icu-65-compat and the libicu*.so autoversioned dependencies, so you are shooting yourself in the foot if you try upgrading package by package just to solve this.

From my point-of-view, I have become very wary of doing `pacman -Syu`, because I have done it several times in the recent past and each time it has resulted in widespread system breakage. The problem I see with the full upgrade is that, if something serious does break, it can be much harder to pinpoint what caused it, if I have just upgraded 100+ packages.

If you upgrade every day, there will hopefully be fewer packages to check. Parabola only syncs once per day IIRC; some Arch users upgrade multiple times per day and see even fewer deltas.

Regardless: upgrading piecemeal like this changes the case from "you might see widespread system breakage on -Syu if there is a bug" to "you absolutely will see widespread system breakage with literally every possible dependency falling out of sync".

In fact, you're not merely shooting yourself in the foot -- you're sawing off both your legs.

Furthermore, the way the library files are set up, with the version number included in the filename, seems to indicate there was some intention for multiple versions to be installed on a system, since the library files don't conflict.

This is simply not true. The version number in the filename is a universal Linux technology to force people to rebuild their stuff when different versions are incompatible with each other. If you try to load both versions into one program (because one program is built against ICU 65 and one of its dependencies is built against ICU 67) you end up with both libraries trying to overwrite each other. Instead of the program refusing to run because it cannot find ICU 65, it will load incompatible code and produce data corruption, undefined behavior, and potentially (though unlikely) it will murder your cat and launch the US nuclear missile stockpile at various targets instead of showing the octave GUI.

The operative concept here is "completely undefined behavior".

...

In the case of ICU, each symbol is versioned, because ICU is explicitly designed to work correctly with multiple versions in parallel. This is why icu-65-compat exists; because it was reviewed and, as a special exception, deemed safe. Do not try to extend this logic to all libraries without reviewing each one on a case-by-case basis.

RE: Ongoing issues with icu ... - Time4Tea - 12 days ago -

bill-auger Ok, thanks for your advice. I see your point about bugs only being fixable on an up-to-date system. That makes sense. I also like your suggestion of having an LTS distro installed on the same machine as a backup. I will look into setting that up and perhaps then plan to run `pacman -Syu` on a more frequent basis. Is there any available tool that can provide a prompt to upgrade at a regular interval (e.g. once per week?).

One suggestion regarding the icu compat package: why not rename it simply 'icu-compat' and then update it to include the N-1 versions whenever a new version of icu is released? That way, anyone that has it installed will maintain backwards compatibility just by upgrading that package, rather than having to install a new one each time icu up-revs.

eschwartz ok, you make some fair points there and I appreciate your input.

To me, the situation with icu seems a bit strange though. My (possibly incorrect) understanding is that part of the reason for having the whole 'dynamically shared library' concept in the first place is to some extent de-couple libraries and the packages that depend on them. So that, if you upgrade a library, you are not forced to have to rebuild all the dependent packages as well. So, this dependency of so many packages on very specific icu versions seems to make icu a poor candidate for the dynamic library model, doesn't it? Would it not be more robust to instead statically link icu to the packages that need it, so they are guaranteed to have the correct version?

Besides, why is there such a hard dependency on specific icu versions, anyway? It seems to be much less backwards-compatible with its dependents than many other libraries.

RE: Ongoing issues with icu ... - bill-auger - 12 days ago -

Time4Tea wrote:

I also like your suggestion of having an LTS distro installed on the same machine as a backup.

sure, any other system, or even a LiveISO would do as a back-up
plan - that was not exactly my suggestion though - my suggestion
was to install another parabola system with the linux-libre-lts
kernel; and to actually use both systems, alternately - use one
for two weeks, then switch to the other, and continue using that
one for two weeks, running pacman -Syu on the first day of each
switch - you could even setup so that they share a home
directory; so the transition would be transparent and un-eventful

Time4Tea wrote:

Is there any available tool that can provide a prompt
to upgrade at a regular interval (e.g. once per week?).

'octopi-notifier' is a taskbar icon which shows when
upgrades are available up-to-the minute - it does not show a
prompt, but is always visiable, changing color from green to red
when upgrades are available

other than that, there are many calendar/todo-list type programs
which you can set to show you arbitrary scheduled reminders of
anything

Time4Tea wrote:

why not rename it simply 'icu-compat'
and then update it to include the N-1 versions

yes that is the plan - 'icu-65compat' was the first experiment
to make sure that it works

    (1-6/6)