[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Rebuilding RPMs results in bad update behavior

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]