[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: Strange dependencies added by rpmbuild



First of all thanks for the assistance, I'll try to clarify things
inline.

> 


Mazda Motor Logistics Europe NV, Blaasveldstraat 162, B-2830 Willebroek
VAT BE 406.024.281, RPR Mechelen, ING  310-0092504-52, IBAN : BE64 3100 0925 0452, SWIFT : BBRUBEBB

-----Original Message-----
> From: redhat-list-bounces redhat com 
> [mailto:redhat-list-bounces redhat com] On Behalf Of Michael Schwendt
> Sent: zondag 20 januari 2008 21:06
> To: General Red Hat Linux discussion list
> Subject: Re: Strange dependencies added by rpmbuild
> 
> On 20/01/2008, Mertens, Bram <mertensb mazdaeur com> wrote:
> >
> > I didn't cross-check the entire list of dependencies I 
> found with those
> > reported by rpmbuild,
> 
> Why not?
> 
> You really need to check your entire buildroot tree for any files that
> cause these dependencies to be added by rpmbuild.
> 
> > I only checked whether or not the dependencies
> > that are causing the problem were listed by find-requires 
> or not.  And
> > as I wrote they are not.
> 
> Uh? In your original post you showed that find-requires lists them and
> adds them to the package. Now you say it doesn't?

Let me try to explain again, looks like I left some things out.

I build the rpm by running the binary installer on a "build-machine"
then creating a tarball from the installed files and packaging those.
The installer succesfully installs the files so I *hope* (don't have
much confidence in the CA stuff anymore) that it would check the
required libraries before installing.

The build-machine is a RHEL4 and the machine I wanted to install the
resulting RPM on is currently still a RHEL3 machine.

Because it complained about those 3 dependencies and because those
"odbc" libraries didn't appear to make much sense to me (the agent
should only contact its so-called policy server not a DB directly) I
tried to figure out why those were reported as dependencies by RPM while
the installer obivously didn't need them.  It didn't even consider them
important enough to throw a warning.
Also the guys who installed this stuff before me used to use the binary
installer on each machine and those 3 library files are missing on all
of the servers where this software is running on.
My guess is that these dependencies are in act dependencies of the
installer itself "InstallAnywhere by Macrovision" rather than the
software itself.  The installer appears to install several additional
files with the software - probably part of the non-working uninstall
script.

I tried to confirm my guess by trying to locate the file responsible for
this dependency.  That's why I was only looking for these three files in
particular.  To do so I manually executed the commands that
find-requires performs as documented in the link I sent.  Following
these steps I was not able to find the files that require these odbc
libraries and the "libverify.so(VER_1)".  I couldn't find either in the
dependencies retrurned by these commands but I may have made a mistake
while adjusting and executing the various commands.

> > Do I understand correctly that these dependencies are in fact
> > dependencies for building the CA siteminder agent?  And as such not
> > needed when running it?
> 
> No, they are dependency of the binaries, such as executables, shared
> libraries, object files, ... and more as I've explained briefly in
> previous reply. An executable that depends on a specific shared
> library SONAME won't run when that library cannot be found.

Thanks again for explaining this.  This appears to "prove" that those
dependencies are not really required by the siteminder software itself -
OR at least not by those parts that we use.  Perhaps whatever you build
round such an agent determines what functionality you need.
But as I wrote the agent has been working without these libraries.

> > Because as I wrote these dependencies aren't available on the system
> > where I built the RPM so the binary installer allowed the 
> installation
> > while it couldn't find those files.
> 
> Did it look for those libraries at all?

That I don't know, I have found that it does strange things that make it
difficult to properly create an RPM from it.

> > > > But they are not listed (well "libverify.so" is but not
> > > > "libverify.so(VER_1)").
> > >
> > > VER_1 is a version symbol you can find in the library with
> > > readelf/objdump and similar tools.
> >
> > Just to understand these things: then why are both libverify.so and
> > libverify.so(VER_1) reported as dependency?
> 
> Because both build a set of requirements, and because at rpmbuild-time
> there is no extra logic that determines whether one provides the
> other.
> 
> > In the mean time I remembered that the machine I'm building 
> the RPMs on
> > is a RHEL4 machine and the machine I'll be installing it on 
> is a RHEL3
> > machine.  Could that cause problems?
> 
> What other problems do you think of? ;o)

Compatability issues between RPM on REHL3 and RHEL4, I thought perhaps
rpmbuild adds dependencies based on the machine it is running on.

> >The software itself should run on both.
> 
> Well, does it run?

After installing the software with --nodeps it does appear to work
correctly.  At least it hasn't segfaulted yet like the previous version.

I hope this clarifies what I have (not) done.

Regards

Bram



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]