Re: MySQL 4.0.x and RH 9

[Tim Mooney <mooney dogbert cc ndsu NoDak edu>]

In regard to: Re: MySQL 4.0.x and RH 9, Andre Costa said (at 12:23am on Sep...:

>Hi James,
>
>On Sun, 31 Aug 2003 10:01:47 -0400 (EDT)
>James Olin Oden <joden@malachi.lee.k12.nc.us> wrote:
>
>[...]
>> RPM is running a script that scans perl scripts and libraries for
>> "use" and "require" lines.  You need to go through MySQL's sources and
>> see if there are anyone ones that call for the (the) perl module
>> (which I have never heard of by the way, and it seems like a false
>> positive).  If it is a false positive, then you can do something silly
>> in their spec file like:
>>
>> 	Provides perl(the)
>
>I agree with you, and I had even gone through CPAN looking for a "the"
>module; no luck. It really seems like a false positive. ... which makes
>me wonder what could have caused it. Any hints?

I don't recall seeing an answer to this question, but if someone else beat
me to it, sorry.

To figure out what caused it, you can use a couple of strategies:

- Do a package build and get things installed into your buildroot, but
don't actually generate RPMs (i.e. rpmbuild -bi).

- Generate a list of all the files that were installed into your
  buildroot:

	find YOUR_BUILD_ROOT -print > /tmp/flist

- iterate through that list, running the perl "find-prov" script for
  each file:

	for f in `cat /tmp/flist`
	do
		echo
		echo "Provides for $f:"
		echo "$f" | /usr/lib/rpm/perl.prov
	done


That should tell you which file in the list is the culprit.

Once you know which file is doing it, you can try debugging what it is
in that file that's cause the perl.prov to generate bogus output.

Tim
-- 
Tim Mooney                              mooney@dogbert.cc.ndsu.NoDak.edu
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164