On Fri, Mar 18, 2011 at 01:10:01PM +0100, Xavier Chantry wrote:
> On Fri, Mar 18, 2011 at 12:55 PM, Lukas Fleischer
> <firstname.lastname@example.org> 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 .