Matthew Miller wrote:
On Mon, Jun 11, 2007 at 11:33:29PM -0400, J French wrote:
Now, when I go to rpm -Uvh the resulting rpm, I get "the installed
version is NEWER than this one". How in the world is this even possible?
So now, any packages I rebuild get marked as older than the binaries?
echo '%dist .fc8.jfrench' >> ~/.rpmmacros
Right, why should I have to do that?
Oh yes, one last thing: On my dual Opteron 246 running in 32-bit mode (I
use 32-bit for my desktop for compatability reasons), rebuilding
Compatibility with what, exactly? You can run, for example, 32-bit firefox
on an otherwise 64-bit system for the best of both worlds....
I have the 64-bit version of 7 which I'm going to install tonight, but
if the bugs I expressed I was being bitten by in Test 4 are still there,
it won't be there in the morning. These bugs included Firefox crashing X
when closing a tab with absolutely no indication as to why, X crashing
when switching VT's and a few others - I filed bugs on all of them. If
they haven't been fixed, I'll reassert that 7 should never have been
released like that. I seriously couldn't get any real work done.
Metacity and Nautilus make the desktop *very* much more responsive than
the binary packages. No surprise there, the only real surprise was when
I'm actually a little surprised. Can you qualtify your results?
Qualtify it? When I log in, my desktop is ready to use in about 2-4
seconds as opposed to around 10-15. When I'm full out working, with a
plethora of applications, instances of applications and whatnot running,
I don't see any window drawing lag as I do with the binaries. I rebuilt
Firefox too, and I'm here to tell you it also starts WAY faster than the
binary install did when no other instances are running. On top of this,
OpenOffice, which I haven't yet touched (yet), now takes 4 seconds to
start as opposed to 12 before - I have no idea why this is though, I
didn't think OOo called on either Nautilus or Metacity *that* much.
My Athlon 64 3000+ desktop with half the RAM (4GB opposed to 8GB) has
about the same responsiveness as the dual Opteron 246 running with the
binaries. The reason I don't find this surprising is that I suspect the
single processor system is closer in architecture to the original build
host and, both processors are indeed used with the binaries, the code's
just more optimized for that system when it's compiled on that system.
This is system optimization 101 and has sparked many debates on the web
about using RPMs as opposed to compiling from source. The "correct"
method when installing or updating RPMs on a production server (where
optimization is key) has always been to download the source and build an
RPM from that or rebuild a src.rpm, which you then install on the
server. Yes, this means dealing with dependency hell a little bit (and
there are some insane dependencies these days), but that's why we make
the big bucks and gcc uses different optimization code for 32-bit and
64-bit processors (even though I'm running in 32-bit mode, I saw gcc
say "checking for 64-bit host: yes") as well as seeing a difference in
Athlon and Intel processors and quite a few other optimizations.
Regardless of why I might want to build my own RPMs on system,
regardless of if I'm seeing much improvement: The point I'm trying to
make with this is that a binary RPM that I make on June 11th of
packagename-1.1 should take precedence over an RPM of packagename-1-1
made on March 3rd - no matter who made it. People running servers in
production environments who care more about those servers than to just
"yum install whatever" are going to have these same issues. I know
Fedora isn't exactly geared toward servers (even though it's being used
on quite a few of them), but the downstream RHEL is and some
consideration should be taken on the issue anyway for those of us who
like to tweak the daylights out of our systems. I mean, why would you
want to make customization of a Linux system harder without *very* good
reason to do so?
I'm off to install the 64-bit Fedora 7 on the dual Opteron system, I'll
take some startup times from the fresh install, repeat the RPM rebuilds
and take some times from that and post them back here when I'm done.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
