[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
