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.