[arch-dev-public] WARNING: [testing] broken due to openssl and heimdal rebuilds

Dan McGee dpmcgee at gmail.com
Wed Apr 7 06:04:32 CEST 2010

On Tue, Apr 6, 2010 at 10:36 PM, Pierre Schmitz <pierre at archlinux.de> wrote:
> On Tue, 6 Apr 2010 15:22:02 -0500, Dan McGee <dpmcgee at gmail.com> wrote:
>> On Tue, Apr 6, 2010 at 3:15 PM, Thomas Bächler <thomas at archlinux.org>
>>> Upgrading still fails: pacman itself works after the small upgrade. But
>>> all post-install scripts in the -Syu that use vercmp are broken. For
>>> example, kernel26 post-install failed on a -Syu for me.
>> I'm trying to figure out how this happens. pacman and vercmp should
>> have idential link libraries, so if one works, the other should (and
>> if one doesn't, the other shouldn't).
> I was able to reproduce this problem. Here it is:
> The first run of pacman -Syu will just update pacman which does not
> directly link to openssl. So the system will still be fine. The second run
> will update everything else. During this update openssl is updated. The
> prbolem is that libarchive and libfetch are not updated right after the new
> version of openssl is installed. This means that all install scripts
> calling vercmp will fail until the new libs are installed.
> This is some kind of general problem: the system may be inconsistent
> during the process of updating and install scripts will fail. In this case
> we need to make sure that libarchive and libfetch are updated right after
> openssl. This might be solved by increasing the versioned deps of pacman to
> libarchive/libfetch to their latest versions which should pull in the new
> openssl. The problem is that doing so the system is inconsistent/broken
> after the first -Syu run.

All makes sense now. I'm just afraid of the inconsistent step you
noted above, as I know I have caught myself in it before and it is
quite painful to be in.

> @Dan: you told me it might be possible to just include the needed object
> files of libalpm into vercmp, so that it does not link against it anymore;
> maybe that would be a more elegant solution. (or include the needed code on
> source level? no idea how this was implemented)

Yes, but this will not be a quick fix, but I should have something
ready for the next release that will allow us to do this.


More information about the arch-dev-public mailing list