[omniORB] RPM spec: python 2.0 dependency?

[Thomas Lockhart]

>>Oh! Duncan, how would you like to keep these syncronized with the actual 
>>source RPMs? Sander and I use the RPMs themselves to document the spec 
>>file (at least partly because in the event of patches the spec file is 
>>not sufficient to fully specify an RPM). Folding in changes from other 
>>places is easy. We just need to know to do it...
> Sorry, I've been meaning to mention the RPM issue, but it kept
> slipping behind other things. I had a need to build some RPMs, so I
> took your spec files and found I had to tweak them a bit. It makes
> sense to me that the spec files should live in the omniORB and
> omniORBpy distributions. I'd appreciate it if you (and anyone else)
> could submit patches to make them work.

OK (though the issue of possible source patches has not been addressed, 
and is a significant point since the spec file itself is not in general 
sufficient to build RPMs).

Are you now taking responsibility for the RPM builds, or can you leave 
that delegated to others such as Sander and myself? It is pretty much 
just a communication issue in practice...

> The issue with __init__.py files from omniORB and omniORBpy
> conflicting is odd, since I had already encountered it, and fixed it
> for my builds. Somewhere along the line, the fix was lost. I'll put
> the fix back in.

Sander and I are building from the source RPMs we have posted, not from 
a modified spec file on the omniORB site so there is no reason to think 
that the fix was ever found ;) The file conflict itself is partly due to 
recent versions of RPM failing to complete if files are left out, and 
the __init__.pyc *not* being identical when built at two different times 
(must be a timestamp or something like that in the file). RPM does not 
complain on installation about __init__.py, which is identical between 
the two packages.

I'll try snarfing that spec file and merging with our most recent version.

                     - Tom