Patching RH SRPMS was: Re: [WBEL-users] Glade Freezes

[John Morris]

On Wed, 2005-06-01 at 20:58, Kirby C. Bohling wrote:

>     Just curious, what's the threshold for patching a RedHat
> package?  I'm fairly sure you backed away from doing this for
> several other (I remember at least one you publically thought out
> loud about it) packages earlier.

The threshold here is that RH's glade runs and mine doesn't.  If someone
can find the magic build order, gcc version, whatever, that allowed RH
to get a working build I'd probably do that instead.  Similar to the
situation with the dhcp package in WBEL4; it also has a patch from
bugzilla because RH shipped a binary built on an earlier gcc because it
was known the gcc shipped with RHEL4 could not build their srpm of
dhcpd.

>     I kinda like the "absolutely RedHat modulo artwork and some
> text".  I actually felt kinda uncomfortable about CentOS when Johnny
> mentioned it earlier (it seems kinda out of the spirit of a
> rebuild).  This seems like a trivial but from reading the patch.  I
> can't say I object, but I'm kinda surprised if RedHat doesn't feel
> like rolling out a new package that you feel the need to.

I think we can hold the line at patching when it is required to achieve
a working package when RedHat's package does work.  This keeps the rule
"if it is broke on RedHat it gets entered into their bugzilla and fixed
when the patch comes from upstream but if RedHat's version works and
mine doesn't it is a build error and thus my problem."

Basically we have to face up to the fact that sometimes RH releases an
srpm that flatly doesn't build on the target distribution.  Such has
happened in the past and will happen again.  Since they currently show
zero inclination to flag such a bug as anything other than
"CLOSED-WONTFIX", "CLOSED-NOTABUG" or "CLOSED-RAWHIDE" it leaves three
options, include a Rawhide package, fix the supplied package so that it
builds and runs or delete the package.

>     Goodness knows I wish RedHat would release any number of
> packages more often when they fix a trivial bug (ghostscript using
> /dev/random instead of /dev/urandom, meanwhile the kernel had a bug
> that meant /dev/random couldn't add entropy to the pool if the pool
> ever emptied, so ghostscript would hang indefinitely if it was used
> in large batch runs is the one I found the most irritating).

Agree that taking on those sort of patches in the mainline leads to
madness.  Next thing ya know it is fork city and the .bomb VC dollars
just ain't there anymore for me to think of ramping up into the next
Mandrake.  :)

-- 
John M.      http://www.beau.org/~jmorris     This post is 100% M$Free!
Geekcode 3.1:GCS C+++ UL++++$ P++ L+++ W++ w--- Y++ b++ 5+++ R tv- e* r