Rebuilding RPMs results in bad update behavior

[Matthew Miller]

On Tue, Jun 12, 2007 at 01:13:09AM -0400, J French wrote:
> >echo '%dist .fc8.jfrench' >> ~/.rpmmacros
> Right, why should I have to do that?

You don't "have" to do anything. You want your local packages to 1)
automatically be easily identifiable as such and 2) automatically beat
Fedora packages, you *should* do that. I recommend also making your own
"subrelease" if you've made any changes.

> 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.

Not sure about the Firefox issue, but the rest sounds like buggy video
drivers. What card?


> >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 

Well, I'll be happy with "quantify".


> seconds as opposed to around 10-15. When I'm full out working, with a 
> plethora of applications, instances of applications and whatnot running, 

This amount of change is almost certainly due to something other than
recompiling your applications for another architecture.

> 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 

No, that really, really isn't the correct method. The correct method is to
use binaries that have gone through QA.


> 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 

Not automatically it shouldn't. The date should have nothing to do with it
-- it should only do what it's explictly told. And you're telling it the
wrong thing, so no surprise that it's not doing what you want.

However, if you want to disagree with me, hey, it's a free world, and you
can in fact define your dist tag to automatically incude the current date
and time -- problem solved.


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>