pacman: asynchron repos, unawareness of dependencies

harlekin · 2006-11-06 20:09:42

Hello.
All the time using archlinux I went really well with pacman. But nowadays I get from now and then some nerved problems when upgrading or installing packages.

Sometimes there are dependencies like shared libraries missing. Especially I got to know about these errors concerning gaim-svn and vlc.
Mostly I solved these errors with creating a link to the latest library I could find in /usr/lib but obviously and as well told here it isn't the best way to do this.

Today I recommended a friend to use gaim-svn as well. He installed it via # pacman -Sy gaim-svn but got the errors I mentioned above as well. Nothing unexpected except that gaim tells him that it's missing another library than the one I haven't got. (in this case libexpad.so.0) So took a look in /usr/lib to see how my system solved this conflict cause I never linked a file called libexpad. And I got to know that I don't have this file either but gaim (the same version) is not requesting it.

Well in general. What causes the problem? Is it the fact that I have nearly all reposities enabled (current, extra, unstable, testing) or lies the problem in the reposities because of asynchron mirrors? Or why isn't pacman not as smart as I got to know it? ):

And especially: How can I solve this problems. How can I used only fully synchronized mirrors? Or is there another solution?

Thanks for any advice and sorry for my bad English. ):

noriko · 2006-11-07 14:00:20

{all correct me if i'm wrong}

gaim and gaim-svn re not the same, the codes are somewhat different, so the depends are likely to be different...

#pacman intel.. the depends section in the pakage will say something like... pkg >= 1.6, now, if it latest version is 2.5 .. then u may find that wen looking for the lib version it might look for .so.0 as a generic name when the lib pkg installs a symlink as so.2 ... it's generally safe afaik to link to whatever so.2 links to... .. i often do that and if it works i keeps it that way...

btw, are you sure you didn't mean "libexpat" ?

harlekin · 2006-11-07 14:51:48

Yes I mean libexpat. And both me and a friend of mine have gaim-svn (even the same built version). But his gaim(-svn) refuses to start because libexpat.so.0 fails. My gaim works well without libexpat.so.0. But I've got libexpat.so.1 instead of .so.0. There is no symlink.

But I want to know why this is happening in general. I see many posts about pacman ignoring shared library dependencies. But there was no clue just conjectures about maybe the ftp server not being synced.

But I want to know why this is happening and how I can prevent it.

Thanks anyway. (:

noriko · 2006-11-07 19:42:19

umm i've experienced these problems many times.. and i'm pretty sure it has nothign to do with pacman... it's more a package issue... since pacman installs what's in the package, as opposed to build it..
added note.... the expat pkg has so.1 only, no so.0, however i've linked to the expat shared object,.. via so.0 and everything is stable here... so i'm guessing it'd be safe to simply link to it, and file a bug report..

ln -s /usr/lib/libexpat.so.1.5.0 /usr/lib/libexpat.so.0

or better yet

cp /usr/lib/libexpat.so.1 /usr/lib/libexpat.so.0

Snowman · 2006-11-08 00:40:37

These problems happens because apps are compiled against specific version of libraries (the number after the .so). When the library version changes (is updated), the apps must be rebuilt against the newest library.

When you get these kinds of errors, make sure that your system is up-to-date (pacman -Syu) and that your server is up-to-date. If the error is still there, it means that the package must be rebuilt so submit a bug report (if its an official package) or notify the TU is it's a community package.

Symlinking libs is not recommended. You can easily rebuild the package. Get the PKGBUILD from ABS, then run makepkg and pacman -U. Usually you don't need to modify the PKGBUILD.

harlekin · 2006-11-08 14:58:44

Thanks. That's exactly what I wanted to know! (=

How can I choose a server depending on if it's up to date?
Or how can I check if he is?

byte · 2006-11-08 17:40:57

harlekin wrote:

How can I choose a server depending on if it's up to date?
Or how can I check if he is?

Start here: Mirrors
Pick a server in one browser tab/window and load the Arch Linux homepage in another, have a look at the dates in the "Package Repositories" section to the right.
On the mirror browse to, for example ".../extra/os/". Compare the Last-Modified date of the "i686" directory to the date on the Arch homepage.
Personally I wouldn't choose a mirror that's more than 20 hours behind.

Snowman · 2006-11-09 02:36:11

byte wrote:

harlekin wrote:
How can I choose a server depending on if it's up to date?
Or how can I check if he is?
Start here: Mirrors
Pick a server in one browser tab/window and load the Arch Linux homepage in another, have a look at the dates in the "Package Repositories" section to the right.
On the mirror browse to, for example ".../extra/os/". Compare the Last-Modified date of the "i686" directory to the date on the Arch homepage.
Personally I wouldn't choose a mirror that's more than 20 hours behind.

I want to clarify the part about "up-to-date servers". First make sure to use the same server for all your repo (current, extra, community) otherwise you might get this problem if one server is more up-to-date than the other one.

Usually these servers issues happens when a lots of packages are moved from the testing repo to the stable ones. If you update your system while the packages are still being moved from testing to current/extra or while your mirror is syncing, you'll miss some packages and will get these libraries issues. These big moves are usually announced on the news, ML and/or forum. If you update your system regularly (daily/weekly) and you get several 100's of MB of packages, it's probably one of these big move. Usually , wait a day or two before updating your system to make sure your mirror has fully synced.

cyberpatrol · 2006-12-02 00:11:35

Snowman wrote:

These problems happens because apps are compiled against specific version of libraries (the number after the .so). When the library version changes (is updated), the apps must be rebuilt against the newest library.
... or notify the TU is it's a community package.

Snowman, can you, please, tell me how I can find out which TU I shall inform when I find such a "library bug" in a community package?

I'm currently having such a problem with community/cinelerra-cvs 20060120-1 and its dependency extra/openexr 1.4.0a-1, but `pacman -Qi` tells me that ArchLinux is the packager of cinelerra-cvs.

And wouldn't it be better or easier to add a category "Packages: Community" to Flyspray to file bugs of packages of the community repository?

Snowman · 2006-12-02 02:00:54

You need to check the package's AUR page. It has the TU name (that you can click to get the TU contact info). You can also leave a comment in the AUR page. For cinelerra-cvs, it already been done.

EDIT: The bug tracker is not used for community packages because the community repo is not an official repo.

cyberpatrol · 2006-12-02 06:50:21

Thank you for the infos, Snowman.
I didn't know that the packages in the community repository are still in the AUR. Now I get it.

Arch Linux

#1 2006-11-06 20:09:42

pacman: asynchron repos, unawareness of dependencies

#2 2006-11-07 14:00:20

Re: pacman: asynchron repos, unawareness of dependencies

#3 2006-11-07 14:51:48

Re: pacman: asynchron repos, unawareness of dependencies

#4 2006-11-07 19:42:19

Re: pacman: asynchron repos, unawareness of dependencies

#5 2006-11-08 00:40:37

Re: pacman: asynchron repos, unawareness of dependencies

#6 2006-11-08 14:58:44

Re: pacman: asynchron repos, unawareness of dependencies

#7 2006-11-08 17:40:57

Re: pacman: asynchron repos, unawareness of dependencies

#8 2006-11-09 02:36:11

Re: pacman: asynchron repos, unawareness of dependencies

#9 2006-12-02 00:11:35

Re: pacman: asynchron repos, unawareness of dependencies

#10 2006-12-02 02:00:54

Re: pacman: asynchron repos, unawareness of dependencies

#11 2006-12-02 06:50:21

Re: pacman: asynchron repos, unawareness of dependencies

Board footer