Responses inline below:
On Sat, Jan 5, 2013 at 11:10 AM, Jeffrey Johnson <n3...@me.com> wrote:
>
>
> Second, you're right, I'm using rpm 4.8 from RHEL. It's the only choice I
> have.
>
>
>
> OK.
>
> FYI: there's not enough difference to worry about between @rpm.org <-> @
> rpm5.org.
>
> The goals are more different than the code is: RHEL "support" is a deadly
> sea-anchor
> to change. So @rpm5.org has more -- and more aggresive -- features.
>
>
Unfortunately, enterprise customers generally have artificial requirements
that force them to use tools that have support. Without RHEL, they almost
certainly would have gone Microsoft.
> Next, at least in my case, setting the -x flag doesn't change anything.
>
>
> I have the following line in the %install section
find $RPM_BUILD_ROOT -name \*.so\* -exec chmod -x {} \;
prior to packaging, no shared libraries have the executable bit set. I
think this is what you meant.
As for the dependencies, you're correct in that there is no reason to
suspect that they aren't required. The problem I'm experiencing is that
all the dependencies that are required are being supplied by the local
package, but RPM is generating external dependencies because it sees the
need for a Requires and isn't noticing that it was supplied as a Provides.
Note that there may be a typo: note the extra '/' character within
parentheses:
Error: Package: endeca-toolsandframeworks-3.1.1-1.el6.x86_64
(/endeca-toolsandframeworks-3.1.1-1.el6.x86_64)
Requires: endeca-mdex=6.4.0
See if that is in the package requirements
rpm -qp --requires endeca-toolsandframeworks-3.1.1-1.el6.x86_64.rpm
That is interesting. I'm building a multi-subpackage RPM, and endeca-mdex
is a requirement for endeca-toolsandframeworks.
Here is the relevant package section from my spec
--- snip ---
%package mdex
Version: %{mdex_version}
Group: Servers/Indexing
Summary: Endeca MDex %{version}
%description mdex
Endeca is an index engine
This is the MDex portion
%package presentationapi
Version: %{mdex_version}
Group: Servers/Indexing
Summary: Endeca MDex Presentation API %{version}
Requires: endeca-mdex=%{version}
%description presentationapi
Endeca is an index engine
This is the Presentation API found in the MDex installer
%package platformservices
Version: %{pfs_version}
Group: Servers/Indexing
Summary: Endeca PlatformServices %{version}
Requires: endeca-mdex=%{mdex_version}
%description platformservices
Endeca is an index engine
This is the Platform Services
%package toolsandframeworks
Version: %{tfw_version}
Group: Servers/Indexing
Summary: Endeca Tools and Frameworks %{version}
Requires: endeca-mdex=%{mdex_version}
endeca-platformservices=%{pfs_version}
%description toolsandframeworks
Endeca is an index engine
This is Tools and Frameworks for Endeca
--- snip ---
I have all versions set with %defines because they'll keep moving forward
and need to be rebuilt each time.
If you have any information about how I could filter using rpm 4.8 I'd
appreciate it.
Filtering in rpm-4.8 is fairly complex (compared to rpm5).
But filtering basically involves writing a 1 line wrapper script
to a helper to post-process stdout to remove a token using sed(1).
(rpm5 implements the same token removal by applying patterns
to tokens, and excluding, w/o the need for scripts & helpers).
There's a bunch of macros in rpm-4.8 (and conventions) that are supposed to
assist
with the filtering, but add complexity from the conventional choices/names
of parameters
used in wrappers etc.
According to the data I could glean initially, that's what all the %globals
were in my original post. I spent about an hour trying to get them
stabilized.
I think filtering changed dramatically from 4.8 to 4.9. Since I don't yet
have 4.9, I believe I'm stuck with the way you were describing. I found a
few articles describing how people did it (the new way) so I'll probably be
able to glean enough data from them (and from pending requests to RH
support) to make this work.
