'Requires' directive in spec file ignored?

[Brian Reichert]

I've never seen this one before:

I'm developing an RPM, with a %post scriptlet that invokes some
classic UNIX commands (grep, sed, etc.).

I can build my RPM, but I found that the commands in my %post
scriptlet weren't showing up as automatically-found dependancies
for my RPM. (rpm -q --requires -p foo-1-1.i386.rpm)

So, I went ahead and expressly added them as requirements:

Requires: /sbin/chkconfig
Requires: /bin/cp
Requires: /bin/grep
Requires: /sbin/service
Requires: /sbin/ldconfig

My RPM builds just fine, but these expressly-stated requirements
_still_ aren't being reported by the RPM.

So, I chased which RPMs provide those resources:

Requires: chkconfig coreutils grep initscripts glibc

And _still_ the requirements aren't being reported by the RPM.

This is under CentOS 5.1. I reviewed my build of the RPM under
RHEL4 update 5, and it had the same symptoms. The other umpteen
dozens of RPMs built over the years seem to honor the 'Requires'
directives.

Has anyone seen this symptom before? I have no idea how to diagnose
this, other than instrumenting python code...

FWIW, I haven't redefined any macros, or anything...

[Jeff Johnson]

Post by Brian Reichert
I'm developing an RPM, with a %post scriptlet that invokes some
classic UNIX commands (grep, sed, etc.).
I can build my RPM, but I found that the commands in my %post
scriptlet weren't showing up as automatically-found dependancies
for my RPM. (rpm -q --requires -p foo-1-1.i386.rpm)
Requires: /sbin/chkconfig
Requires: /bin/cp
Requires: /bin/grep
Requires: /sbin/service
Requires: /sbin/ldconfig

Smells like a goofy spec file syntax problem, like unclosed macro, or
Requires:
oddly placed.

Post a link to your spec file, perhaps I can spot the problem.

73 de Jeff

[Brian Reichert]

Post by Jeff Johnson

Post by Brian Reichert
Requires: /sbin/chkconfig
Requires: /bin/cp
Requires: /bin/grep
Requires: /sbin/service
Requires: /sbin/ldconfig

Smells like a goofy spec file syntax problem, like unclosed macro, or
oddly placed.
Post a link to your spec file, perhaps I can spot the problem.

Hey, if you're willing to look:

http://www.numachi.com/~reichert/misc/mDNSResponder.spec

Thanks for any feedback...

Post by Jeff Johnson
73 de Jeff
_______________________________________________
Rpm-list mailing list
https://www.redhat.com/mailman/listinfo/rpm-list

[Jeff Johnson]

The spec file you posted has this:

Summary: mDNSResponder
Name: mDNSResponder
Version: %{version}
Release: %{release}

The "Version: %{version}" causes a macro recursion because
after Version: is parsed, one ends up defining version to itself.

Basically same as doing
%define version %{version}
which can never be evaluated.

After commenting out all the elements in, I see dependencies:

$ rpm -qp mDNSResponder-1.2-3.*.rpm --requires
/bin/sh
/bin/sh
/bin/sh
/sbin/ldconfig
/sbin/ldconfig
executable(chkconfig)
executable(chkconfig)
executable(cp)
executable(cp)
executable(grep)
executable(sed)
executable(service)
executable(service)

73 de Jeff

[Brian Reichert]

Post by Jeff Johnson
Basically same as doing
%define version %{version}
which can never be evaluated.

I supply the macro in an external file, so I don't see that complaint.
And I don't:

rpm -q --requires -p mDNSResponder-107.6-2.i386.rpm
/bin/sh
/bin/sh
/bin/sh
/bin/sh
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.3)
libdns_sd.so
libpthread.so.0
libpthread.so.0(GLIBC_2.0)
libpthread.so.0(GLIBC_2.1)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1

Post by Jeff Johnson
$ rpm -qp mDNSResponder-1.2-3.*.rpm --requires

So - what platform are you building your RPM in?

Post by Jeff Johnson
/bin/sh
/bin/sh
/bin/sh
/sbin/ldconfig
/sbin/ldconfig
executable(chkconfig)
executable(chkconfig)
executable(cp)
executable(cp)
executable(grep)
executable(sed)
executable(service)
executable(service)
73 de Jeff

[Tim Mooney]

Post by Brian Reichert

Post by Jeff Johnson
Basically same as doing
%define version %{version}
which can never be evaluated.

I supply the macro in an external file, so I don't see that complaint.
rpm -q --requires -p mDNSResponder-107.6-2.i386.rpm
/bin/sh
/bin/sh
/bin/sh
/bin/sh
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.3)
libdns_sd.so
libpthread.so.0
libpthread.so.0(GLIBC_2.0)
libpthread.so.0(GLIBC_2.1)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1

Assuming rpm is using executabledeps.sh to actually generate the
dependencies in the executable() namespace, then the first version of
"bash" in your PATH must support the --rpm-requires hack. Does your
version of bash support that?

Tim

[Brian Reichert]

Post by Tim Mooney
Assuming rpm is using executabledeps.sh to actually generate the
dependencies in the executable() namespace, then the first version of
"bash" in your PATH must support the --rpm-requires hack. Does your
version of bash support that?

Looks like it:

% /bin/bash --rpm-requires
executable(/etc/bashrc)

Post by Tim Mooney
Tim
--
Information Technology Services [phone] (Voice)
Room 242-J6, IACC Building [phone] (Fax)
North Dakota State University, Fargo, ND 58105-5164
_______________________________________________
Rpm-list mailing list
https://www.redhat.com/mailman/listinfo/rpm-list

[Brian Reichert]

Post by Jeff Johnson
Summary: mDNSResponder
Name: mDNSResponder
Version: %{version}
Release: %{release}
The "Version: %{version}" causes a macro recursion because
after Version: is parsed, one ends up defining version to itself.
Basically same as doing
%define version %{version}
which can never be evaluated.

I elected to hard-code the version info, to test your hypothesis, but the
oucome was the same. :/

Post by Jeff Johnson
73 de Jeff

[Rex Dieter]

Post by Brian Reichert
http://www.numachi.com/~reichert/misc/mDNSResponder.spec

neat. :) Here's a mDNSResponder.spec that I worked on for fedora/redhat
awhile back:
http://kdeforge.unl.edu/apt/kde-redhat/SOURCES/mDNSResponder/

(never got enough round-tuits to finish submitting it)

-- Rex

[Brian Reichert]

Post by Rex Dieter

Post by Brian Reichert
http://www.numachi.com/~reichert/misc/mDNSResponder.spec

neat. :) Here's a mDNSResponder.spec that I worked on for fedora/redhat
http://kdeforge.unl.edu/apt/kde-redhat/SOURCES/mDNSResponder/
(never got enough round-tuits to finish submitting it)

Cool to compare. What's that '%ghost' directive?

I tried to emply the scriptlet notation you do:

Requires(preun): chkconfig, /sbin/service
Requires(post): chkconfig
Requires(postun): /sbin/service

but the symptoms don't change...

Post by Rex Dieter
-- Rex

[Brian Reichert]

Post by Rex Dieter

Post by Brian Reichert
http://www.numachi.com/~reichert/misc/mDNSResponder.spec

neat. :) Here's a mDNSResponder.spec that I worked on for fedora/redhat
http://kdeforge.unl.edu/apt/kde-redhat/SOURCES/mDNSResponder/

Annoyingly, your spec file _does_ properly have it's requirements
handled under CentOS 5.1. :/

I'll try to carefully blend our spec files, and I think I store
more than you do from the distribution...

Post by Rex Dieter
-- Rex

[Brian Reichert]

Post by Brian Reichert

Post by Rex Dieter
neat. :) Here's a mDNSResponder.spec that I worked on for fedora/redhat
http://kdeforge.unl.edu/apt/kde-redhat/SOURCES/mDNSResponder/

Annoyingly, your spec file _does_ properly have it's requirements
handled under CentOS 5.1. :/
I'll try to carefully blend our spec files, and I think I store
more than you do from the distribution...

So - I've successfully blended the two spec files. You spec file
broke things out into separate packages, mine delivers some additional
files (javadoc, an additional command-line tool, etc.) If you have any
personal interest in the results, let me know.

What I _still_ don't get, though, is why my spec file does work
under RHEL4 or CentOS 5.

Nor do I know how to debug this. Someone earlier mentioned they
could use my original spec to create an RPM that had the requirements
properly handled, but I have no idea what environment that was done
in.

Does anyone have any advice on how to chase this? Or do I have to
start pawing through reams of anaconda code to chase this down?