tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: p5-* modules and DEPEND for tests

In article <> Ulrich wrote:
: [-- text/plain, encoding 7bit, charset: us-ascii, 53 lines --]

: >   We should use the same mechanism we use for hiding installed C
: > libraries to hide installed Perl module: symlink all files from Perl
: > modules listed as dependencies into a directory inside WRKDIR and set
: > the Perl include path to that.  That way, from Perl's perspective,
: > only the listed packages are available, and pkgsrc will ensure that
: > they are also available when installing the binary packages later.

: I am not sure if you can set the @INC path of a Perl binary exclusivly,
: I think it's compiled in, but I may be wrong with this.

  While the environment variable PERL5LIB is added to the standard
include path, setting @INC in a BEGIN block replaces the standard
include path.  So we could write a wrapper perl script that sets @INC
and then executes the real script.

: Perl -V shows me:

: [...]

:   Built under netbsd
:   Compiled at Jun 26 2008 11:19:14
:   @INC:
:     /usr/pkg/lib/perl5/site_perl/5.8.0/i386-netbsd-thread-multi
:     /usr/pkg/lib/perl5/site_perl/5.8.0
:     /usr/pkg/lib/perl5/site_perl
:     /usr/pkg/lib/perl5/vendor_perl/5.8.0/i386-netbsd-thread-multi
:     /usr/pkg/lib/perl5/vendor_perl/5.8.0
:     /usr/pkg/lib/perl5/vendor_perl
:     /usr/pkg/lib/perl5/5.8.0/i386-netbsd-thread-multi
:     /usr/pkg/lib/perl5/5.8.0

: They are set inside Perls I am not sure if we can't change
: this. The buildlink system is a great concept and I really would like to
: see something for Perl things as well. However, there are some Perl
: packages who require alot packages as dependencies (like 30), this would
: lead to a massive symlinking which might be a serious impact, especially
: on the slower machines.

  So do the buildlink and wrapper frameworks, and we currently try to
speed them up.  Still, I think repeatable builds are worth the
overhaed: The build enironment of the package developer and the
package builder should be as simmilar as possible.

: >   I would leave this up to the discretion of the package maintainer.
: > If the maintainer is sure a certain package is only used during build
: > or test, he should mark them appropriately.  Maybe we can add a
: > recommendation to the pkgsrc guide that, when in doubt, use a full
: > dependency.

: You already said it - if in doubt. We don't have that many maintainers
: for Perl things anyway. I think it would make updating alot easier. I am
: trying to fix the dependencies to make life for later updates alot
: easier. Just increments the version number, run the test-suite and check
: if it fails or not. So I think the full dependency should be the
: default.

: It also helps our users to check if their Perl work correctly and if
: everything is fine.

  I don't know how well written perl module Makefiles are, and how
accurate the dependency lists are, but I wouldn't put too much trust
in the dependencies listed in configure scripts of non-perl packages.
My experience is that they are often badly maintained and don't list
packages installed in default Linux distrubtions.  So blindly copying
them over to the Makefile is not a policy I want to see documented in
the guide.


Home | Main Index | Thread Index | Old Index