On Fri, Mar 18, 2011 at 01:10:01PM +0100, Xavier Chantry wrote: > On Fri, Mar 18, 2011 at 12:55 PM, Lukas Fleischer > <archli...@cryptocrack.de> wrote: > > Hi, > > > > I'm not really sure if this actually is a bug or intended behaviour but > > upgrading pacman man my freshly installed system with [testing] enabled > > just broke pacman: > > > > $ pacman > > pacman: error while loading shared libraries: liblzma.so.5: cannot open > > shared object file: No such file or directory > > > > After some investigation, I figured out that "liblzma.so" is part of > > xz-utils which was renamed to "xz" sometime ago. When doing the first > > full system upgrade, pacman asked me to upgrade itself, first. As > > "SyncFirst" packages seem to be pulled in without dependency resolution, > > I ended up in having pacman 3.5.0, but an old xz-utils, resulting in > > some broken pacman depending on some shared library of a package that > > hasn't been upgraded yet. > > > > Is that intended? Unfortunately, I'm in a rush and I don't have any time > > to analyze this in detail right now... > > > > > > dep resolution is done, but if the deps are not precise enough, it > does not help. > Another example where sodeps could have been useful :) > > As far as I can see, libarchive 2.8.4-2 got a versioned dep on xz >= 5 > but pacman only depends on libarchive 2.8.0
Right, ye. I literally only had 10 minutes to figure this out and made wrong assumptions, thank your for clearifying. The pacman package in [testing] should be fixed anyway - before moving it to [core]. Otherwise, all fresh installs will break on the first system upgrade. Opened a Flyspray ticket [1]. [1] https://bugs.archlinux.org/task/23325