Date: Sun, 7 Nov 2004 16:35:14 +0300 From: Solar Designer <solar@...nwall.com> To: owl-users@...ts.openwall.com Subject: Re: Owl-current moved to glibc 2.3.x Maciek, I'm really surprised you went through all that trouble. What you were supposed to do is a simple "make installworld" over your older system. That would have taken care of all the issues you mention automagically. But I'll comment on them anyway: On Sun, Nov 07, 2004 at 04:11:36AM +0100, Maciek Pasternacki wrote: > When upgrading, I noticed some inconsistencies: > > One is not bumping up the release on all recompiled packages Yes, we're indeed well aware of it and, while definitely not elegant, this is intentional. There's simply no obviously-correct way to decide when a package's release number should be bumped. If we would spend the time to determine whenever a library a package depends on has been changed (or would develop a set of scripts to track that) and would bump release numbers each time this happens, that would result in a lot of mostly unnecessary changes to spec files. OK, the glibc change is a significant one. And so is OpenSSL. But what about all the smaller changes, such as re-building with new gcc? For C++ code, this is a significant change too (dependencies on libstdc++ change), but for plain C?.. Should we go ahead and bump release numbers in almost(?) all spec files each time we update gcc? Basically, currently it is assumed that by far the most Owl users will use "make installworld". And if you do install packages manually, you need to realize that a matching package version number between Owl-current revisions or between different branches does not imply the package is built/linked against all the same library versions. > Currently > poldek doesn't compile OOTB on Owl because of some autotools magic not > detecting librpm correctly; Is that still the case with the latest Owl-current? > as soon as I'll get my system completely > up and running I'll track this down with poldek developers. Oh, so you aren't fully upgraded yet? It should have taken just a few minutes with "make installworld", really. :-) > Second inconsistency is /usr/lib/rpm/macros -- default cpu is now > i686; since I run i586 system, I was surprised by rpmbuild creating > i686 binaries for me (even more surprised by it running > i686-pc-linux-gnu compiler and saving resulting binaries as .i386.rpm > files). Are binaries in -current also compiled for i686-pc-linux-gnu? > Why such change? Or maybe I don't understand some details about > compiling for different flavours of x86? Now, this may be a bug, and I wasn't aware of it. I'll let Galaxy investigate and fix it. He's the boss at our rpm package presently. But the Owl-current i386 binaries that are now on our FTP mirrors correctly do not require an i686. (Actually, you wouldn't be able to get this far on your i586 if they did.) So I do not think this bug had any consequences. > Also, the way of upgrading RPM is bothersome Sorry to repeat it, but "make installworld" takes care of the issues you mention. > (or, at least, rpm %pre script could be more informative, > maybe even print exact shell commands to convert the database without > doing too much harm to the system). Perhaps it should be made Owl-aware: detect that rpm is not running from within "make installworld" and explain that it probably should be. Thank you for sharing this experience with the list! We do need to know if something is not documented clearly enough. Apparently, the upgrade procedure isn't. -- Alexander Peslyak <solar at openwall.com> GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598 http://www.openwall.com - bringing security into open computing environments
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.