Rebuilding RPMs results in bad update behavior

J French me at semitekie.com
Tue Jun 12 05:13:09 UTC 2007



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.




More information about the fedora-devel-list mailing list