On Jan 5, 2013, at 4:02 PM, Mykel Alvis wrote:
>
> devzero2000 over on the rpm-users list suggested
> %define _use_internal_dependency_generator 0
>
>
> This did exactly what I needed.
>
>
Yes but … there are profound changes to the *.rpm package
format that are coupled to setting %_use_internal_dependency_generator to 0.
That macro was _NEVER_ designed to be flipped around on a per-package basis
by package monkeys.
For starter, your package is not multilib ready (which will cause issues on
path collisions,
particularly for ELF libraries), and is generally
The Wrong Fix
You also cannot use --filerequire to see which files generated which
dependencies.
The better fix examines the dependencies and finds out why they
dependencies don't match.
There is no reason at all -- EIGHT YEARS LATER -- to believe that
the dependency extraction based on ELF data is incorrect. In gafact it
is both correct and well tested, just5 that packagers have lost whatever
knowledge about how to compile programs they might once have had
because of the insane complexity of GNU tools like autoconf/automake.
Hint: Run
readelf -a libfoo.so | grep SONAME
I'll bet your libraries do not have an soname. the string "SONAME" aka DT_SONAME
is mapped into a Provides, the "NEEDED" string aka DT_NEEDED is mapped into a
Requires:.
Including a DT_SONAME in the library is now harder than passing a
singlr option to the linker like
-WL,so name,THIS_IS_MY_SONAME
73 de Jeff
>
> 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
>
>
