Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: libtiff: Library dependency problems in at least xsane and digikam. (Read 1770 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

libtiff: Library dependency problems in at least xsane and digikam.

digikam and xsane do not start anymore after an update due to broken library dependencies.

First, update and explicit installation of the Artix' versions of the softwares:

Code: [Select]
pacman -Syu world/libtiff world/digikam omniverse/xsane

Then, trying to start:

digikam:
Code: [Select]
digikam: error while loading shared libraries: libtiff.so.5: cannot open shared object file: No such file or directory


xsane:
Code: [Select]
xsane: error while loading shared libraries: libtiff.so.5: cannot open shared object file: No such file or directory

I have to install Arch's extra/xsane to make xsane work, and Arch's extra/digikam together with Arch's extra/opencv to make digikam work.

Versions in the repos:

pacman -Ss '^(libtiff|xsane|digikam)$' | grep -v '^[[:space:]]':
Code: [Select]
world/digikam 7.9.0-2 [installed: 7.9.0-4]
world/libtiff 4.5.0-1 [installed]
omniverse/xsane 0.999-5 [installed: 0.999-6]
extra/digikam 7.9.0-4 [installed]
extra/libtiff 4.5.0-1 [installed]
extra/xsane 0.999-6 [installed]

My Artix mirrors are:


xsane is in the omniverse repository, there I use the following mirror:

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #1 –
Yeah sorry about that, the kde update is still in process (in the testing repos). Those should be built against the new library so once the move happens that should resolve this.

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #2 –
xsane in the omniverse repo should work, pls test

artist

Update as atomic operation?

Reply #3 –
Ahoj,

thanks for the explanation!

A remark:

Quote from: Dudemanguy – on
Yeah sorry about that, the kde update is still in process (in the testing repos). Those should be built against the new library so once the move happens that should resolve this.

Would it be possible to have the move all at once as an (almost) atomic operation, so that there is either a complete consistent set of working packages of the old versions available in the "production" repos, or a complete consistent set of packages of the new versions available in the "production" repos, but not a mixture?

For an everyday-to-use-operating-system it is not really reliable if it on the one hand suggest frequent full upgrades, on the other hand there is always reason to fear that some software needed for work breaks.

Those problems seem to appear every now and then (I "feel" more often than on Arch, and contrary to Arch which, if such things happen, publishes guides for fixups timely on the main page http://archlinux.org/, for Artix there is usually no such information at all), this is not the only issue of this kind.

Regards!

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #4 –
Quote from: dreieck – on
Would it be possible to have the move all at once as an (almost) atomic operation, so that there is either a complete consistent set of working packages of the old versions available in the "production" repos, or a complete consistent set of packages of the new versions available in the "production" repos, but not a mixture?
The inter-repo move is practically atomic. Packages known to break things go first into goblins/staging until rebuilds/updates have finished and then moved into production. However, slip-ups do happen from time to time...
 

Re: Update as atomic operation?

Reply #5 –
Quote from: dreieck – on
For an everyday-to-use-operating-system it is not really reliable if it on the one hand suggest frequent full upgrades, on the other hand there is always reason to fear that some software needed for work breaks.

Strange.
I always thought that the admins and not the developers or package maintainers were responsible for system maintenance.
"Wer alles kann, macht nichts richtig"

Artix USE="runit openrc slim openbox lxde gtk2 qt4 qt5 qt6 conky
-gtk3 -gtk4 -adwaita{cursors,themes,icons} -gnome3 -kde -plasma -wayland "

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #6 –
Quote from: lq – on
Strange.
I always thought that the admins and not the developers or package maintainers were responsible for system maintenance.
And you'd be correct.

But mismatched libraries, within just the Artix repo's, doesn't fall under normal system maintenance. That's package maintenance.

I know how to fix such issues and I'm sure you do too. But not all Artix users do. And ideally they shouldn't have to. In this case digikam was broken for around a week. Why xsane is not in the normal repos I have no idea?
I'm not complaining. On a scale of 1 to 10 I care about 0.3 but @dreieck makes a reasonable point.

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #7 –
Quote from: dreieck – on
Would it be possible to have the move all at once as an (almost) atomic operation, so that there is either a complete consistent set of working packages of the old versions available in the "production" repos, or a complete consistent set of packages of the new versions available in the "production" repos, but not a mixture?
It's not really an infrastructure problem (well I say this but our buildserver is down for some reason as I type this which delays things :P) but kind of just bad luck. Arch recently did a massive amount of rebuilds on us (I can't recall this many in such a short time period happening before) which took a while to catch up. I guess we could have held back the libtiff updates, but a ton of packages were affected by that and people were noticing soname mismatches in arch packages so it's probably better that we moved them.

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #8 –
Quote from: gripped – on
But not all Artix users do. And ideally they shouldn't have to.

Imho, everyone who sets up an OS is an admin and as such he MUST know what he is dealing with, this applies not only to the software but also to the hardware.

The trick is: you don't have to learn how to solve problems, you should learn how to prevent problems.
"Wer alles kann, macht nichts richtig"

Artix USE="runit openrc slim openbox lxde gtk2 qt4 qt5 qt6 conky
-gtk3 -gtk4 -adwaita{cursors,themes,icons} -gnome3 -kde -plasma -wayland "

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #9 –
Quote from: Artist – on
xsane in the omniverse repo should work, pls test

No, I won't test now, because I am afraid that things will break again when I install Artix' libtiff. Now I have xsane and digikam working with Arch's libtiff, and as long as not all Artix shipped packages are built against Artix' libraries I will not change that.

I know that I can test and revert as long as I have the old packages still in my pacman cache, but I trust you that xsane is now linked agains the correct libtiff and I will for now stick with the packages at the current version.

I will wait a week or so, then try a full update.

Quote from: lq – on
Imho, everyone who sets up an OS is an admin and as such he MUST know what he is dealing with, this applies not only to the software but also to the hardware.

The trick is: you don't have to learn how to solve problems, you should learn how to prevent problems.

This sounds like a double bind dilemma here: On the one hand, I am supposed to do frequent full updates. On the other hand, only after the update the problems that the packages provided by the distribution are improperly linked.

Preventing here would be to have some system snapshotting which takes a system snapshot before each pacman run, than a revert is easy. But that takes extra storage locally and on some laptops local storage is scarce.

I know how I can fix this (as a last resource: Grab the PKGBUILD and build locally, resulting in linkage to the locally installed libraries), but from my perspective the distribution is responsible for taking care that the packages they ship are correctly linked.

Mistakes can happen, and that is OK.

Quote from: nous – on
The inter-repo move is practically atomic. Packages known to break things go first into goblins/staging until rebuilds/updates have finished and then moved into production. However, slip-ups do happen from time to time...

With "atomic" I mean, when there is some new package version, it will only be relased to the production repositories if all packages that depend on that package that is new have been rebuilt (if necessary, recursively if there are recursive dependencies), and only after all rebuilds habe been done all those packages are moved at the same time to the production repositories.

Quote from: Dudemanguy – on
Arch recently did a massive amount of rebuilds on us[...]. I guess we could have held back the libtiff updates, but a ton of packages were affected by that and people were noticing soname mismatches in arch packages so it's probably better that we moved them.

You mean, users who were using packages not from Artix' repositories but from Arch's repositories (e.g. from "community" or "extra"), because those packages are not available in Artix' repositories?

Well, I see the point, given that this really creates some tension with my thought of "atomic" and I see that there can be no overall clean solution then as long as Arch's and Artix' packages are mixed, and I see that this mixing can be practical.


Regards!,
and thanks for all your maintanance work!

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #10 –
digikam should be updated in our repos now. btw, I'm not actually sure why we don't just import xsane into the repos.

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #11 –
Quote from: Dudemanguy – on
and people were noticing soname mismatches in arch packages so it's probably better that we moved them.
I've had another think about this. It's a strange logic imho. Adding the Arch repos is 'unsupported'. Yet if there was truly a decision to update libtiff to prevent breakage of packages installed from the Arch repos, knowingly (or not) breaking libtiff dependant packages in the Artix repo, it comes across as - in this instance - Arch repo users were more supported than pure Artix users.

Just a thought. Again not complaining, discussing.

Praise be Artix, and hallowed be the devs who give up their free time to maintain it.

digikam now complains about missing 'libZXing.so.1'.

Reply #12 –
Quote from: Dudemanguy – on
digikam should be updated in our repos now.

But there still is a library problem. Can you please do a test before you make a fix via an update to something that is reported to have problems?

The problem now is:

Code: [Select]
digikam: error while loading shared libraries: libZXing.so.1: cannot open shared object file: No such file or directory

/usr/lib/libZXing.so* belongs to the package zxing-cpp, and both Arch and Artix have version 2.0.0.

Quote from: Artist – on
xsane in the omniverse repo should work, pls test

It works now.

Rergards!

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #13 –
Quote from: dreieck – on
But there still is a library problem. Can you please do a test before you make a fix via an update to something that is reported to have problems?
Sorry, I didn't realize that digikam had to be moved from testing. That should solve it this time.

Re: libtiff: Library dependency problems in at least xsane and digikam.

Reply #14 –
Quote from: Dudemanguy – on
Sorry, I didn't realize that digikam had to be moved from testing. That should solve it this time.

And I still had opencv from the Arch "extra" repository (version 4.7.0-1) on my system, from my previus workaround to the issues reported in this thread. Now, when I downgraded to Artix' world/opencv (version 4.6.0-6), digikam first complains about libopencv_dnn.so.407:

Code: [Select]
digikam: error while loading shared libraries: libopencv_dnn.so.407: cannot open shared object file: No such file or directory

A new version of digikam has not yet arrived at my mirror. 
As general Artix mirrors I use:
Code: [Select]
Server = http://mirror1.artixlinux.org/repos/$repo/os/$arch
Server = https://eu-mirror.artixlinux.org/repos/$repo/os/$arch


I am now resorting to build digikam-git from the AUR, because I am fed up with this right now.

Regards and thanks again for your work and efforts!