[omniORB] omniORB 4.1.5?

[Thomas Lockhart]

> I obviously don't know yet what the new spec files from Steffan and
> Thomas look like. Do you know about the packages I build in the openSUSE
> build service? As of this moment, my spec files are successfully
> building Fedora 13, RHEL 5, SLE 11 SP1, openSUSE 11.1 - 11.3, all both
> i586 and x86_64 architectures, for omniORB, omniORBpy, and omniEvents.
> Obviously I like the package granularity I've implemented. That said,
> there is room for improvement that I already know about, and there are
> probably even more improvements possible, so I am quite interested I
> seeing the "other" new RPM spec files.
>   
No, I somehow didn't know or forgot that the build farm had omniORB in 
it. Here are the "merged" spec files and below I'll try to point out 
what is different or not already captured in the *_new.spec versions in 
the head of the tree. The RPM granularity seems to be the same as the 
other spec files. Have you evolved your spec file since those were 
committed? Anyway, perhaps we can find time in the next few days to 
complete a merge and get the RPMs in the source repository updated and 
the *_new.spec files removed.

                                        - Tom

Some spec file differences:

In the *_new.spec files: they use the "libomniorb" naming convention for 
the -devel packages as well as the basic installation package. I looked 
at my Fedora 14 machine and noticed that most packages seem to use the 
actual package name (e.g. "omniORB") for everything but the libraries 
base package. So I folded that convention into the "merged" spec files.

The *_new.spec files define the variable "_name" at the top of the file. 
afaict this is unnecessary: "name" is defined by the RPM keyword "Name:" 
and is usable throughout the file.

Version numbers are scattered through the *_new.spec files leading to 
maintenance issues. Define version number variables at the top of the 
file and use those variables in the rest of the file.

The release number should contain the optional %{?dist} field.

The "Prereq" keyword is deprecated (rpmbuild on Fedora 14 prints a 
warning about this). Substituted "Requires" instead.

Some of the distro-specific prerequisites and other code protected by 
tests against the "_vendor" keyword seem to be different. Maybe support 
for "mandriva" should be retained? You are building against a fairly 
broad range of distros; does the build farm also do an install to test 
that aspect of the packaging?

I added "Provides" arguments which use "omniorb" so there is 
"libomniorb", "omniorb", and "omniORB" in the "Provides" stanzas.

Use the %{name} substitution in the command line for starting the 
servers rather than an explicit "omniORB".

Include the release notes in the documentation.

The omniORB_new.spec development RPM has a %dir directive and includes 
all of the omniidl_be/cxx directory, where the "merged" spec file 
includes specific files from that directory. I'm vaguely recalling that 
including the entire directory may give some files which are not 
desirable; perhaps you could check the contents of one of your builds to 
verify that you don't have more than you want?

The *_new.spec %{_datadir}/idl specification does not use a wildcard 
(e.g. %{_datadir}/idl/*) but I guess the wildcard is not necessary.

*_new.spec uses "py_sitedir" and "py_sitearch" where the "merged" spec 
files use "py_dir" and "py_execlibdir". bfd.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: omniorb_spec.tar.gz
Type: application/x-gzip
Size: 4634 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20101124/a7e0f3b2/omniorb_spec.tar.bin