[omniORB] 4.0.0 RPMs

[Sander Steffann]

Hi Thomas,

I also built RPMs for 4.0. I asked Duncan to look at them, but I suspect he
didn't have the time to look at them yet. I had to make similar patches to
install in a diffirent directory. On my system (RH73) the IDL installed into
/usr/share/idl by default, su I didn't have a problem with that.

You can find my RPMs at http://www.steffann.nl/omniORB/ (the RH6.2/7.0
directories are old omniORB302 RPMs) if you want to look at them.

Bye,
Sander

----- Original Message -----
From: "Thomas Lockhart" <lockhart@fourpalms.org>
To: "omniORB Mailing List" <omniORB-list@realvnc.com>
Sent: Wednesday, May 29, 2002 12:35 AM
Subject: [omniORB] 4.0.0 RPMs


> I've built RPMs for omniORB and omniORBpy for a 4/26 snapshot tarball.
> The following issues came up:
>
> 1) Typically an extra path prefix is defined in the makefiles to allow
> "installing" into something other than the intended installation area,
> so something like RPM can take those files and package them up. DESTDIR
> is typically used for this, and is typically left blank for non-package
> builds. The line defining a path then looks like $(DESTDIR)$(prefix) and
> make has DESTDIR set on the command line.
>
> 2) The IDL files are installed into $prefix/idl. istm that this should
> be configurable to allow setting this to be somewhere other than
> /usr/idl (which does not otherwise exist on my Mandrake 8.1 Linux box).
> I do see a /usr/share/idl which has an ORBit directory and what is
> probably something left over from omniORB 3.x. I'm not very familiar
> with autoconf-2.5x and am not certain what the preferred way to add an
> option of this nature is. My recollection is that for older autoconf
> configure.in files, I'd see examples right in the code. Is there a file
> system standard suggested for the location of IDL files? My inclination
> would be to put them under /usr/include/omniORB (or something) rather
> than defining an otherwise unused area like /usr/idl. Suggestions?
>
> 3) The catior utility has the same name as a similar utility in TAO. So
> RPMs built for both packages and targeted at /usr will conflict. I
> renamed catior to be "omnicatior" for now; any suggestions for better
> (non-conflicting) names?
>
> 4) Same issue of DESTDIR for omniORBpy.
>
> I've enclosed a patch file for the first two issues (item (1) seems to
> be easy; not sure if my patch for item (2) is appropriate). I've also
> included a patch to cover item (4), same as (1) but for omniORBpy.
>
> I'm not sure the best way to release RPMs. I understand that not much
> has been done for 4.0.x and RPMs yet; if folks would be interested in
> these I'd be happy to contribute them...