On Fri, 2009-07-31 at 13:35 -0400, Seth Vidal wrote:
> I think swig has a bug in its packaging.
>
> specifically
>
> perl(ExtUtils::MakeMaker)
> perl(argv)
> perl(example)
> perl(it)
> perl(the)
>
> I think those last 4 are an error.
>
> at least I hope so.
>
They are. They come from the file Doc/Manual/Perl5.html, that has the
following lines:
use ExtUtils::MakeMaker;
<snip>
use it without success, you can build a new version of the Perl
<snip>
use example;
(multiple itmes)
<snip>
use the use command as normal. For example :
<snip>
(more use example)
<snip>
use argv;
<snip>
use of Perl code might be to supply a high-level interface to certain
functions.
<snip>
Each of those are going to trigger the perl require checker to think
those are perl modules if it is ran on this html file.
The spec has:
cat << \EOF > %{name}-req
#!/bin/sh
%{__perl_requires} `perl -p -e 's|\S+%{_docdir}/%{name}-doc-%{version}\S
+||'`
EOF
%define __perl_requires %{_builddir}/%{name}-%{version}/%{name}-req
chmod +x %{__perl_requires}
which is going to go through the doc dir, where this html file is found,
and scour it for requires. Does the same for provides which may also
screw things up.
So where is the bug? That the provider/require script is being ran on
html files, that the script is reading html files and treating them like
perl files?
We'll need to get a new version of swig built to fix this, however it
needs to be fixed.
On Fri, 2009-07-31 at 13:35 -0400, Seth Vidal wrote: > I think swig has a bug in its packaging. > > specifically > > perl(ExtUtils::MakeMaker) > perl(argv) > perl(example) > perl(it) > perl(the) > > I think those last 4 are an error. > > at least I hope so. > They are. They come from the file Doc/Manual/Perl5.html, that has the following lines: use ExtUtils::MakeMaker; <snip> use it without success, you can build a new version of the Perl <snip> use example; (multiple itmes) <snip> use the use command as normal. For example : <snip> (more use example) <snip> use argv; <snip> use of Perl code might be to supply a high-level interface to certain functions. <snip> Each of those are going to trigger the perl require checker to think those are perl modules if it is ran on this html file. The spec has: cat << \EOF > %{name}-req #!/bin/sh %{__perl_requires} `perl -p -e 's|\S+%{_docdir}/%{name}-doc-%{version}\S +||'` EOF %define __perl_requires %{_builddir}/%{name}-%{version}/%{name}-req chmod +x %{__perl_requires} which is going to go through the doc dir, where this html file is found, and scour it for requires. Does the same for provides which may also screw things up. So where is the bug? That the provider/require script is being ran on html files, that the script is reading html files and treating them like perl files? We'll need to get a new version of swig built to fix this, however it needs to be fixed.