Skip to main content
Topic: broken dependencies (Read 3998 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

broken dependencies

Hi, i was wondering what people generally do with this. It is not a huge problem; just like in another thread from mrbrklyn, when you get a package compiled with a wrong version of the library and get an error like:

mplayer: error while loading shared libraries: libcdio.so.18: cannot open shared object file: No such file or directory

artix is not a mainstream distribution, and it's repos probably don't get updated as much as the arch repos, which are still used as dependencies, therefore there is inevitable package breaking once in awhile. I don't mind having to do a little bit of manual version management; i wouldn't be in this forum if i wanted a system completely managed for me  :P.

I was just wondering how people generally approach this. Notice a library file missing, downgrade the package, blacklist it in pacman.conf, and then wait a while to try it again? Is there a different, maybe more automated approach that people generally take?

Re: broken dependencies

Reply #1
Are you running Artix-testing or stable?
If you are on testing do you also have community-testing?
I don't know of an automated way to deal with this, I just mention it here that something broke and within 24hrs or less it is fixed.
Just don't expect too much explaining on how and when.  It is like magic, you mention it, it gets fixed.
That's the artix way.  It is also a mixed distribution, not because artix is slow in developing new pkgs, and the foundation is like quicksand.  Arch does not warn artix on how things change, artix must always catch up to the changes and what they affect.

Ideally there should have been an unstable part running on arch testing, and testing running on stable arch.  Maybe in reality that is how it is done.

Re: broken dependencies

Reply #2
I usually downgrade, and then use '--ignore' to not upgrade it, till Artix has updated the package.

Re: broken dependencies

Reply #3
Quote
mplayer: error while loading shared libraries: libcdio.so.18: cannot open shared object file: No such file or directory
I have the same error, but with mpv and libcdio. Only way I found to resolve it was downgrading mpv and libcdio.

Best regards.
We should try to be kind to everyone.....we are all fighting some sort of battle.

Re: broken dependencies

Reply #4
@conky60 You don't have to downgrade 'libcdio'. The whole issue is that that package in Artix [stable] isn't up-to-date, w.r.t. Arch.

Re: broken dependencies

Reply #5
@conky60 You don't have to downgrade 'libcdio'. The whole issue is that that package in Artix [stable] isn't up-to-date, w.r.t. Arch.
I am running Artix "testing" repos, and libcdio version in world-testing is the same as Arch "extra" (2.0.0-1). I downgraded to 0.94-2 from Artix "world".

Best regards.
We should try to be kind to everyone.....we are all fighting some sort of battle.

Re: broken dependencies

Reply #6
I think I pulled the new version from testing.  I am wrong about that?

Re: broken dependencies

Reply #7
I think I pulled the new version from testing.  I am wrong about that?
The only two versions my search has revealed is 0.94-2 in Artix "world", and 2.0.0-1 in Artix "world-testing" and Arch "extra".

Best regards.
We should try to be kind to everyone.....we are all fighting some sort of battle.

Re: broken dependencies

Reply #8
OK - I don't know how you ened up with a problem with that library.  In my case, I had an updated version of lib264 and I let the library and updated mplayer from the arch testing which I downloaded from the web site and installed with pacman from the command line.

I use mplayer in my alarm clock - so it sucked when it was broken.

Re: broken dependencies

Reply #9
OK - I confirmed this on the last upgrade.  For gods sake, why is a core app like mplayer have such problems :(

I reinesntalled the old version of mplayer that I had on the hard drive which came off of arch testing a few days back.  Currently, mplayer is completely broken from the arch repos.

 pacman -R /home/ruben/Downloads/mplayer-37998-2-x86_64.pkg.tar.xz

FWIW
https://archlinux.pkgs.org/rolling/archlinux-extra-x86_64/libcdio-2.0.0-1-x86_64.pkg.tar.xz.html
[flatbush ~]# locate libcdio.so
/usr/lib/libcdio.so
/usr/lib/libcdio.so.16
/usr/lib/libcdio.so.16.0.0
[flatbush ~]#

so the system is at least one step back on that lib

Re: broken dependencies

Reply #10
The only two versions my search has revealed is 0.94-2 in Artix "world", and 2.0.0-1 in Artix "world-testing" and Arch "extra".

Best regards.

Doesn't 2.0.0.-1 have the rightr library?

Re: broken dependencies

Reply #11
Doesn't 2.0.0.-1 have the rightr library?
Mpv (through smplayer) complains about not being able to find "libcdio.so.16". The only way I have been able to get mpv to work w/smplayer for me is to downgrade mpv to the previous release from Arch "community" (1:0.27.0-5), and downgrade "libcdio"  to 0.94-2 from Artix "world".
I may be overlooking something....my head hurts. ???


Best regards.
We should try to be kind to everyone.....we are all fighting some sort of battle.

Re: broken dependencies

Reply #12
weirdly, even if i install libcdio from extra insted of world. mpv complains about libcdio.so.18 when i have libcdio.so.16 and complains about libcdio.so.16 when i have libcdio.so.18.

Are you running Artix-testing or stable?

stable

Re: broken dependencies

Reply #13
weirdly, even if i install libcdio from extra insted of world. mpv complains about libcdio.so.18 when i have libcdio.so.16 and complains about libcdio.so.16 when i have libcdio.so.18.

stable
I have noted the exact same as well. ??? 
I have switched from mpv engine to mplayer engine in my smplayer....that works, except for a bit of a video glitch when switching to fullscreen. Once in fullscreen it's ok.

Best regards.
We should try to be kind to everyone.....we are all fighting some sort of battle.

Re: broken dependencies

Reply #14
i wish i could add something constructive