devzero2000 over on the rpm-users list suggested
%define _use_internal_dependency_generator 0
This did exactly what I needed.
On Sat, Jan 5, 2013 at 12:26 PM, Jeffrey Johnson <n3...@me.com> wrote:
>
> On Jan 5, 2013, at 1:07 PM, Mykel Alvis <mal...@restorationhardware.com>
> wrote:
>
> 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.
>
>
>
> (aside)
> If enterprise customers used microsoft instead of RHEL, they would have
> saved oodles of money: RHEL pricing is obscenely expensive. *shrug*
>
> Note that I've used M$ Windows for perhaps 3 months over 30 years of
> uglix: just saying.
>
> 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.
>
>
> Best is to verify the end result that is actually in the *.rpm package.
>
> Using --xml is WYSIWYG for everything: there are also query formats for
> a tag displayed in octal that can be substituted (untested, from memory):
>
> rpm -qp --qf '[%{FILENAMES}: %{FILEMODES:oct}\n]' foo*.rpm
>
> 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.
>
>
> If a "replacement", then you need a Provides: with the other name as well.
>
> 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.
>
>
> I don't see any Provides: for the other names: each package will
> provide its own name. I father are other "virtual" names/aliases,
> then you need to add the Provides:.
>
> Meanwhile that '/' looks odd: either its the error message formatting or
> the '/' character is in the metadata.
>
> Using --requires/--provides with -qp will disambiguate.
>
> 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.
>
>
> <scarcasm>
> Its on the internet: it MUST be true!
> </scarcasm>
>
> There's a lot of erroneous information (and cumbersome procedures) around
> for RPM.
>
> 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.
>
>
> Depends on "dramatically": internal tables were exported to dozens of
> files around 4.9 yes.
>
> Not that what is in 4.9 is going to solve any problem for you on RHEL,
> which will still be using 4.8 years from now.
>
> When building, editing global configuration seldom is useful, so it hardly
> matters whether internal tables or external files are used.
>
> There's also no need for filtering when the automagic dependency
> extraction is correct.
> Newer! Better! Bestest! filtering is solving the wrong problem: change the
> extraction,
> not filter out the mistakes, is the better solution, particularly for ELF
> library dependencies.
>
> JMNSHO, YMMV.
>
> 73 de Jeff
>
>
