At 04:02 PM 8/31/2005, Frank Cusack wrote:
On August 29, 2005 10:27:38 PM -0400 Dan Franklin <dfranklin@xxxxxxx> wrote:
I can get around this by adding Provides: tags for the "missing"
packages, but it seems to me
that perl.prov ought not to scan for package statements. It should
just use the things that
'use' statements actually care about - the filenames themselves.
This is just based on your description, but does Perl also care about
explicit package names inside a .pm? If I don't have a 'use' statement
but just call foo::bar::method, would Perl load foo/bar.pm?
No, that would be an error.
What if
I did 'use foo;' and then called foo::bar::method, and foo.pm defined
the package foo::bar, then wouldn't Perl avoid loading foo/bar.pm?
The 'use foo' would cause Perl to load foo.pm, and then when you
called foo::bar::method it would work fine, since foo.pm defined
it. Perl would not normally load foo/bar.pm based merely on an
attempt to call foo::bar::something.
In which case Perl did care about more than the filename.
It does care about more than the filename, in exactly the same sense
that C++ code cares about more than library sonames. A C++ program
loads dynamic libraries by soname, then its code invokes individual
classes defined in those libraries; a C++ class name may or may not
be related to the filename of the library it's defined in. This is
analogous to Perl's individual packages that may or may not be
defined in .pm files with corresponding names.
So it seems perl.req should look for 'use' AND calls to explicitly named
package methods, and perl.prov should look at filenames AND explicit
package statements.
Yes, it could do that. rpmbuild doesn't currently go down to that
level for C++ code. There is some danger of generating an excessive
list of requirements, since just because a call to an explicitly
named package occurs in the file doesn't mean it will ever occur in practice.
Please comment--I'm not familiar enough with Perl module handling to
be confident in what I'm suggesting.
I think that it's more than what's really needed, and goes beyond the
automatic dependency generating that rpmbuild does for other
languages, but it would be consistent, which is better than the
current situation.
Dan Franklin
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
