On Fri, 2 Apr 2010 17:30:33 +0200, Andreas Radke wrote:

Am Thu, 01 Apr 2010 03:05:28 +0200 schrieb Pierre Schmitz :

...

Hi all,

this is a warning for [testing] users not to update until the upcoming openssl/heimdal rebuilds are done. This will break a lot of important packages. I am bootstrapping openssl and rebuild the most imporant packages like pacman atm. I'll send another mail to the openssl-1.0.0 thread when you can start rebuilding.

Greetings,

Pierre

Most stuff seems usable again.

One question: Because I have to rebuild all OpenOffice packages anyways I'd like to ask what you think about adding another rebuild cycle - ICU 4.4. http://www.archlinux.org/packages/extra/i686/icu/

Not too many packages seem to depend on it. Most time will be eaten by OOo.

Objections?

-Andy

Could you send me the changed so names or just the output of pacman -Qlp https://users.archlinux.de/~pierre

On Tue, Apr 6, 2010 at 3:15 PM, Thomas Bächler wrote:

Am 01.04.2010 03:05, schrieb Pierre Schmitz:

...

Hi all,

this is a warning for [testing] users not to update until the upcoming openssl/heimdal rebuilds are done. This will break a lot of important packages. I am bootstrapping openssl and rebuild the most imporant packages like pacman atm. I'll send another mail to the openssl-1.0.0 thread when you can start rebuilding.

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). Did you have pacman in SyncFirst, and did you do that? -Dan

On Tue, 6 Apr 2010 15:22:02 -0500, Dan McGee wrote:

On Tue, Apr 6, 2010 at 3:15 PM, Thomas Bächler

...

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. @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) -- Pierre Schmitz, https://users.archlinux.de/~pierre

On Tue, Apr 6, 2010 at 10:36 PM, Pierre Schmitz

...

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

On Tue, 6 Apr 2010 23:04:32 -0500, Dan McGee wrote: 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.

I just tested what happens if I change pacman depends to "'libarchive>=2.8.3-3' 'libfetch>=2.30-3'". You need to run -Syu twice but everything works fine. The remaining problem is that if you use anything else than libfetch to get your packages (e.g. wget or curl) you wont be able to update because after the first run those apps are broken. But I still don't see any chance to solve this in a smooth way. So I would change the pacman package that way and post a news item and ask people to run -Syu twice and tell them that external download programs cannot be used. -- Pierre Schmitz, https://users.archlinux.de/~pierre

On Wed, 07 Apr 2010 14:49:19 +1000, "Allan McRae" wrote:

External downloaders can be used. It just has to be done as: pacman -Syuw pacman -Su

So SyncFirst is ignored when using -w? That's even better. So, one need to update in three simple steps then: :P pacman -Syuw pacman -Su pacman -Su -- Pierre Schmitz, https://users.archlinux.de/~pierre

On Wed, Apr 7, 2010 at 12:01 AM, Allan McRae wrote:

On 07/04/10 14:55, Pierre Schmitz wrote:

...

On Wed, 07 Apr 2010 14:49:19 +1000, "Allan McRae" wrote:

...

External downloaders can be used.   It just has to be done as: pacman -Syuw pacman -Su

So SyncFirst is ignored when using -w?

Yeah... maybe not, but the user can choose "N" when asked.

...

That's even better. So, one need to update in three simple steps then: :P pacman -Syuw pacman -Su pacman -Su

Thus the reason I didn't want those deps in there, it gets way too complex. When we roll this whole thing out, can we just post in the news that you should pay close attention to the output and likely will have to `pacman -S kernel26` (and anything else that errored) if you want to be sure things are working OK? Obviously not ideal. Especially now that we've tied a major kernel bump to this, hmm. -Dan