Using merge_config.sh

[Josh Boyer]

On Wed, Feb 01, 2012 at 03:24:23PM -0500, Don Zickus wrote:
> On Wed, Feb 01, 2012 at 01:33:41PM -0500, Josh Boyer wrote:
> > Hi All,
> > 
> > We've been using merge.pl to merge Fedora's config file fragments for as
> > long as I can remember.  However, in the interest of using what's
> > upstream, I took a look at the newly added merge_config.sh script and
> > what it would take to use that instead.
> 
> I remember looking at this last week and thinking the same thing.  I
> remember hacking on merge.pl years ago and optimizing to run really fast.
> Even today there are RH folks who complain it still runs slow.

Yes, merge.pl is rather fast.

I did happen to time _just_ the make -f Makefile.{config,merge} portion
in the %prep section.  merge.pl takes 2 seconds.  merge_config.sh+patch
takes 2m.

> I thought the same as you, why not start using the upstream approach and
> have one less thing to maintain/worry about in the fedora spec file.
> 
> But the major plus with using perl was you could cache the file in memory
> and it only had to be read once.  With the script, files are read multiple
> times which add to the delay.
> 
> There is really no way around it unless upstream converts to perl or
> python or even 'c'.
> 
> So I would be torn and lean away from it until the speed improves.  I know
> if this makes it to RHEL people would complain and it would get ripped out
> in favor of the old way.

If we're going on pure speed then sure.  There's no reason to replace
what is working today with something that is much slower.  What I'm more
interested in though, is either:

1) Does the additional verification from merge_config.sh prove useful
enough to warrant a slowdown?  I can see it being useful to make sure we
don't screw something up on a rebase, etc.

2) Can merge.pl be adapted to produce similar output without making it
much slower?

If I have to go with 2, I'll be replacing merge.pl with merge.py because
I don't speak perl. ;)

Alternatively, we could make it an option to use the upstream stuff so
that if we're doing a rebase or just want to see what the hell is going
on, it's a trivial toggle of something to switch.  I don't think the
code for that would be all that ugly at all.

josh