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
