INSTALL/DEINSTALL script creation within pkgsrc.
If an INSTALL or DEINSTALL script is found in the package directory,
it is automatically used as a template for the pkginstall-generated
scripts. If instead, they should be used simply as the full scripts,
then the package Makefile should set INSTALL_SRC or DEINSTALL_SRC
explicitly, e.g.:
INSTALL_SRC= ${PKGDIR}/INSTALL
DEINSTALL_SRC= # emtpy
As part of the restructuring of the pkginstall framework internals,
we now *always* generate temporary INSTALL or DEINSTALL scripts. By
comparing these temporary scripts with minimal INSTALL/DEINSTALL
scripts formed from only the base templates, we determine whether or
not the INSTALL/DEINSTALL scripts are actually needed by the package
(see the generate-install-scripts target in bsd.pkginstall.mk).
In addition, more variables in the framework have been made private.
The *_EXTRA_TMPL variables have been renamed to *_TEMPLATE, which are
more sensible names given the very few exported variables in this
framework. The only public variables relating to the templates are:
INSTALL_SRC INSTALL_TEMPLATE
DEINSTALL_SRC DEINSTALL_TEMPLATE
HEADER_TEMPLATE
The packages in pkgsrc have been modified to reflect the changes in
the pkginstall framework.
were lost in PKGREVISION nb7. We do this by avoiding inspecting the
value of ${WRKSRC} within the package Makefile and instead deferring
using ${WRKSRC} until we actually need the value (after extraction).
This is necessary because WRKSRC is defined in bsd.pkg.mk, which is
too late.
Bump the PKGREVISION to 8.
CVE-2005-3916 - format string vulnerability in scripts using syslog()
CVS-2005-3962 - format string vulnerability in Perl_sv_vcatpvfn()
Bump the PKGREVISION to 7.
library searches to start in the system directories instead of in the
pkgsrc-controlled directories. This change is in the same spirit as
the one that caused the PKGREVISION bump to 6, but is more likely to
work on IRIX where plibpth needs to be set from the Configure script.
This time, we patch the Configure script instead of setting libpth in
the hints file because we depend on the values of variables which are
defined after the hints file is sourced by the Configure script.
XXX This breaks building perl on a platform that has native pthreads
XXX with PREFER_NATIVE_PTHREADS=no, but that's not really worthwhile
XXX to fix.
applications much sooner. We do this by making every hints file create
a usethreads.cbu script that prepends the correct LDFLAGS to the
ldflags and lddlflags Perl variables. This should fix PR pkg/31091,
which detailed a problem with building threaded perl on a platform
withat native pthreads that used GNU Pth as its pthread library.
While we're here, also fix some minor variable quoting issues.
Bump the PKGREVISION to 6.
perl suffers from an integer wrap overflow inside the explicit
parameter format string functionality. This has been confirmed to
be a vector for remote code execution.
Bump PKGREVISION to 5.
"yes", then they list the compressed manpages. Implementation stolen
from the PLIST MANZ-handling code in bsd.pkg.mk added by Stoned Elipot.
This should fix pkg/31499.
Tests that failed are:
../ext/POSIX/t/posix.t
not ok 3 - read to array element # TODO read to array element not working
# Failed at /home/reed/pkgsrc/lang/perl5/work/perl-5.8.7/ext/POSIX/t/posix.t lin
e 40
# got undef
# expected 'perl
# '
not ok 11 - masked SIGINT received
because some Perl modules make some (bad) assumptions about the
structure of a MakeMaker-generated Makefile. Instead, remove the
perllocal.pod file whenever a p5-* module or perl itself is removed.
While here, rename some of the install/deinstall templates to more
descriptive names.
Bump the PKGREVISION to 3.
$(prefix) == $(siteprefix) == $(vendorprefix)
so that if a perl module is configured with "perl Makefile.PL PREFIX=...",
then that single PREFIX definition will override all three of the
above, and files will be properly installed into the correct relative
path. Also, patch a test so that it understands the different behavior
of the pkgsrc ExtUtils::MakeMaker module. Bump the PKGREVISION to 2.
for many "core" modules, UTF-8 and Unicode bugfixes, and ithreads
bugfixes.
The major changes are in the pkgsrc infrastructure to handle Perl and
Perl modules. All pkgsrc-installed Perl modules are now installed in
"vendor" directories, and the perl interpreter has been modifed to
search for libraries in the following order: site, vendor, perl. The
Perl library is stored in a directory that is named for the Perl ABI
version associated with the Perl release, so any updates of Perl to
newer versions can be done "in-place" as long as Perl ABI version
remains the same. All Perl scripts and man pages are stored in
locations that won't conflict between site, vendor, and perl modules,
and a new utility perllink(1) now manages symlinks to those scripts
and man pages under the usual ${LOCALBASE}/bin and ${LOCALBASE}/man/man1.
PERL5_SITEPREFIX may be set to the prefix where local, site-specific
modules will be installed, e.g. PERL5_SITEPREFIX=/usr/local. Note
that modules installed here are completely unmanaged by pkgsrc.
Update the buildlink and tool dependencies on perl to require perl>=5.8.7
to reflect the new locations for Perl modules and the Perl shared
library.
around at either build-time or at run-time is:
USE_TOOLS+= perl # build-time
USE_TOOLS+= perl:run # run-time
Also remove some places where perl5/buildlink3.mk was being included
by a package Makefile, but all that the package wanted was the Perl
executable.
run-time dependency (DEPENDS) on a tool is to append a ":run" modifier
to the tool name, e.g.,
USE_TOOLS+= perl:run
Tools without modifiers or with an explicit ":build" modifier will
cause build dependencies (BUILD_DEPENDS) on those tools to be added.
This makes the notation a bit more compact.
probably has something to do with how make deals with short-circuit
evaluation of conditionals, but it's a simple matter to split the
conditional since USE_PERL5 is eventually going away.
Plan:
(1) Change USE_PERL5=build into USE_TOOLS+=perl.
(2) Change all other USE_PERL5 into including perl5/buildlink3.mk.
Possibly, for packages that don't actually build anything with perl,
but merely require it for the perl interpreter, we can instead do:
USE_TOOLS+= perl
TOOLS_DEPMETHOD.perl= DEPENDS
but this is more verbose than simply including the perl5/buildlink3.mk
file.
Move the PERL5_REQD computation into a lang/perl5/version.mk file,
and only do the USE_PERL5 logic in bsd.pkg.use.mk if we're not using
the new tools framework. This consolidates all of the perl-handling
into two places -- lang/perl5 and mk/tools/perl.mk.
using them, as these values are referenced till later when the variables
will definitely have the correct value. This removes the need to
include vars.mk here.
we don't want it to find. The usual buildlink techniques don't work
here since the Configure script uses a file existence test instead of
a linker test to see if the library exists. For each operating system
that we support in pkgsrc, there should be corresponding
LIBSWANTED.${OPSYS} and SYSLIBPATH.${OPSYS} definitions in the Perl
package Makefiles to ensure we only get what we ask for.
In this particular case, add the appropriate definitions for OpenBSD
so that we don't pick up random libraries that may also be installed
on the system.
Before, we were possibly using the values gleaned from a pre-existing
perl binary via perl5/vars.mk (pulled in by bsd.pkg.use.mk), which
would lead to the new perl using the pre-existing perl's version-specific
libraries. Bump the PKGREVISION of lang/perl5 to 11 and lang/perl58
to 4.
does. This allows us to use dynamic PLISTs for Perl modules that are
built using Module::Build. Bump the PKGREVISION of p5-Module-Build
to 1.
* Drop the use of PERL5_USES_MODULE_BUILD and introduce a new variable
PERL5_MODULE_TYPE that is either "MakeMaker" or "Module::Build" that
names the framework used to build/install the module.
* Split out the variables set in perl5/buildlink3.mk that are also used
by perl5/module.mk into a new file perl5/vars.mk. Move some PERL5_*
variable definitions from pkgsrc/mk/bsd.pkg.use.mk into perl5/vars.mk.
This just centralizes the common PERL5_* definitions into a single
file location.
* Convert the known packages that use Module::Build to set
PERL5_MODULE_TYPE and PERL5_PACKLIST:
devel/p5-Class-Container
devel/p5-Exception-Class
devel/p5-Log-Dispatch
devel/p5-Array-Compare
textproc/p5-Pod-Coverage
www/p5-Apache-Session-Wrapper
www/p5-MasonX-Request-WithApacheSession
module directory has changed (eg. "darwin-2level" vs.
"darwin-thread-multi-2level").
binary packages of perl modules need to be distinguishable between
being built against threaded perl and unthreaded perl, so bump the
PKGREVISION of all perl module packages and introduce
BUILDLINK_RECOMMENDED for perl as perl>=5.8.5nb5 so the correct
dependencies are registered and the binary packages are distinct.
addresses PR pkg/28619 from H. Todd Fujinaka.
installation needed when including perl5/buildlink3.mk. The only
option currently supported is "threads", which implies that a perl
that supports threads is required. The requirement is checked at
pre-install time using an INSTALL script template by both the package
build and the binary package.
Add PERL5_OPTIONS+=threads to both devel/p5-SDL and graphics/p5-GD
since those modules require a perl that supports threads.
which are the full option names used to set rpath directives for the
linker and the compiler, respectively. In places were we are invoking
the linker, use "${LINKER_RPATH_FLAG} <path>", where the space is
inserted in case the flag is a word, e.g. -rpath. The default values
of *_RPATH_FLAG are set by the compiler/*.mk files, depending on the
compiler that you use. They may be overridden on a ${OPSYS}-specific
basis by setting _OPSYS_LINKER_RPATH_FLAG and _OPSYS_COMPILER_RPATH_FLAG,
respectively. Garbage-collect _OPSYS_RPATH_NAME and _COMPILER_LD_FLAG.
the PERL defintionen in the Makefile resulting from Makefile.PL gets
set to 0 if LANG || LC_<something> is set to something else (read non english).
ok'd by jlam@
Georg Schwarz in PR pkg/25057:
- check for PKGSRC_COMPILER instead of USE_MIPSPRO:
USE_MIPSPRO would imply the former, but not the other way around.
That is, it's conceivable to have a system that has PKGSRC_COMPILER
set (to mipspro), but not USE_MIPSPRO.
- Allow passing of -Duse64bitint if ABI == 64 even if the compiler is not
mipspro. (Note: we could test this on a non-IRIX 64bit platform by
setting ABI to '64'. I think that should work, too, but I can't test
that right now.)
MIPSPro compiler/preprocessor behaves differently if invoked on
stdin vs file. In configure, we test for stdin, but lateron we use files.
So force it to work the way we know it does.
the normal case when BUILDLINK_DEPENDS.<pkg> isn't specified, it receives
a value only once due to the multiple inclusion protection in the
bulldlink3.mk files. In the case where a package includes several
buildlink3.mk files that each want a slightly different version of another
dependency, having BUILDLINK_DEPENDS.<pkg> be a list allows for the
strictest <pkg> dependency to be matched.
MAKE_FLAGS with stuff that's only useful for building modules (and also
breaks the build of perl).
This fixes the breakage of perl modules not finding libperl.so caused by
the changes in revision 1.30 of this file.
and 5.6.1nb10 include pulling in changes from the latest Perl sources
that add a more complete set of directories on NetBSD systems to the
rpath of Perl modules so that they may find libperl.so. The module
build/installation is now robust against the user overriding the value
of INSTALLARCHLIB.
INSTALLARCHLIB. During the build, INSTALLARCHLIB refers to the
directory where libperl.so may be found, which should point into the
default view. During the install, INSTALLARCHLIB refers to the
directory where the perllocal.pod file should be installed, which
should point into the package prefix.
so the the remainder of this file can use their values. Also override the
PREFIX with the module's PREFIX so the default directories end up pointing
in the right place.
bsd.pkg.mk automatically converts PERL5_ARCHLIB to be prefixed by
${LOCALBASE} if this is an overwrite package, so simply strip that away to
get the relative directory.
with binary packages.
XXX We should be adding to and removing from perllocal.pod in
XXX VIEW-{INSTALL,DEINSTALL} actions from the INSTALL/DEINSTALL
XXX scripts.
so add the appropriate buildlink. Doesn't affect NetBSD, but makes this
work under Irix. Apparently this is a change I forgot to commit a long time
ago.
libgcc.a isn't linked "whole archive" into the perl executable on newer
NetBSD systems (>1.5.x). Newer NetBSD systems have libgcc_pic.a linked
into shared libraries, so this hack isn't needed. This change was tested
by building and testing textproc/xerces-p, a C++ perl5 module that uses
functions in libgcc.a.
we install them into a private directory under the the normal Perl
installation and configure Perl so that site-specific Perl man3 pages
are installed into a private directory within site_perl. This avoids
manpage conflicts between 3rd-party modules, the standard Perl library,
and other packages.
The changes implement some unfinished work that is alluded to in the
MakeMaker.pm module by allowing "installsiteman{1,3}dir" to be set
during the configuration process and are used to provide default values
for INSTALLSITEMAN{1,3}DIR during the Perl module build/install process.
Bump PKGREVISIONs for lang/perl5 and lang/perl58.
Makefiles simply need to use this value often, for better or for
worse.
(2) Create a new variable FIX_RPATH that lists variables that should
be cleansed of -R or -rpath values if ${_USE_RPATH} is "no". By
default, FIX_RPATH contains LIBS, X11_LDFLAGS, and LDFLAGS, and
additional variables may be appended from package Makefiles.
using ExtUtils::MakeMaker style Makefile: usually they provide a
'test' target.
So adding 'TEST_TARGET?=test' here gives us a lot of packages with
the test target enabled.
Now a package using this file can be configured by the regular
do-configure target if PERL5_CONFIGURE is _not_ set to YES (which is
the default), and then have a the standard perl configuration step
done by say the post-configure target.
Example:
PERL5_CONFIGURE= NO
post-configure: perl5-configure
Usually in such a case PERL5_CONFIGURE_DIRS would have to be
adjusted, as well as other directory variables. See following commit
to graphics/p5-PerlMagick package for a complete example.
The previous behavior is preserved if PERL5_CONFIGURE default
value is left untouched, i.e. the do-configure target does the
standard perl configuration.
Please note that this new feature was made up by Johnny Lam. Thanks again!
and install perl5 modules.
The following targets are provided by this file:
do-configure runs the standard perl configuration in
each of the directories specified in
${PERL5_CONFIGURE_DIRS}.
The following variables may be set prior to including this file:
PERL5_CONFIGURE if "YES", then run the standard perl
configuration assuming Makefile.PL exists;
defaults to "YES".
PERL5_CONFIGURE_DIRS list of directories in which to run the
standard perl configuration; defaults to
${CONFIGURE_DIRS}.
PERL5_LDFLAGS extra linker flags to pass on to the build
process.
This file also does the PERL5_PACKLIST handling to generate a PLIST. When
all p5-* packages have been modified to use module.mk, then the
PERL5_PACKLIST code in bsd.pkg.mk can be removed.
buildlink2.mk files back into the main trunk. This provides sufficient
buildlink2 infrastructure to start merging other packages from the
buildlink2 branch that have already been converted to use the buildlink2
framework.
changing the default module/library search path to have site_perl come
before the standard directories. In other words, the previous search path
on an i386 was:
/usr/pkg/lib/perl5/5.6.1/i386-netbsd
/usr/pkg/lib/perl5/5.6.1
/usr/pkg/lib/perl5/site_perl/5.6.1/i386-netbsd
/usr/pkg/lib/perl5/site_perl/5.6.1
/usr/pkg/lib/perl5/site_perl
but it is now:
/usr/pkg/lib/perl5/site_perl/5.6.1/i386-netbsd
/usr/pkg/lib/perl5/site_perl/5.6.1
/usr/pkg/lib/perl5/site_perl
/usr/pkg/lib/perl5/5.6.1/i386-netbsd
/usr/pkg/lib/perl5/5.6.1
The rationale for this is that when we install a module that is newer than
one in the standard library, the new module goes into the site_perl
directory as it's an add-on module. However, we can't use the newer module
without modifying either the scripts of the perl environment to find the
newer module explicitly because of the order of the library search path:
the site_perl directories come after the standard directories. The normal
solution is to directly replace the module in the standard library with
the newer module. However, this isn't really on option when installing
via pkgsrc because the older module files are owned by the perl package.
By placing the the site_perl directories before the standard directories,
newer modules that we install via pkgsrc are simply found before the older
ones in the standard library.
provide a way to avoid building a statically linked perl on platforms
where it doesn't matter. Currently, by empirical evidence in pkg/14871,
this includes mipsel and probably mipseb. Other platforms can add
themselves if/when they discover it doesn't matter for them either.
Closes pkg/14871 by John Hawkinson <jhawk@mit.edu>.
we don't accidentally add options that the linker doesn't understand, such
as "-Wl,-R*". This should fix pkg/14907 by John Klos john@sixgirls.org
where the a.out linker ld doesn't understand extra flags passed in from
LDFLAGS from the pkgsrc environment when building a perl package.
from the distfile version number. G/C the version number stuff from
perl5/Makefile.common, preserving only PERL5_DIST_VERS as it's still used
by libperl.
buildlink.mk file can replace the use of USE_PERL5: it defines all of the
same perl variables as bsd.pkg.mk, adds a dependency on perl>=${PERL5_REQD}
and conditionally includes bsd.perl.mk. It also creates a buildlinkified
Config.pm that makes the local include/library search path include
${BUILDLINK_DIR} instead of hard-coding ${LOCALBASE}. There's more to be
done to make this more useful in strongly buildlinkifying a package, but
it's useful now as-is in weakly buildlinkifying a package.
directly against -lperl when built. Combined with the previous update of
perl to add ${LOCALBASE}/lib to the rpath when creating shared
libraries/modules, these two changes make using mod_perl.so (ap-perl) more
painless. All perl shared modules now contain interlibrary dependencies to
the shared libraries they need. Instead of needing (at least on ELF):
LoadFile !/usr/lib/libm.so
LoadFile lib/perl5/5.6.1/i386-netbsd/CORE/libperl.so
...
# Any other libraries needed by perl shared modules need to listed
# with LoadFile here.
...
LoadModule perl_module lib/httpd/mod_perl.so
AddModule mod_perl.c
you'd need only the last two lines as the mod_perl authors intended.
I've tested this patch for many weeks now, successfully loading and using
the p5-Apache-ASP module as my test bed, and I haven't noticed any problems
with normal perl usage.
Also comment the Makefile slightly better.
modules) about -Wl,-R. We cause -Wl,-R/path/to/libdir in LIBS settings
to now get propagated correctly to the link command for shared modules.
The rpath flag is also silently coerced to start with -Wl,-R or -R
depending on the contents of ${LDDLFLAGS} to deal with either cc or ld
being invoked.
* Ensure that shared objects/libraries created by perl Makefiles include
the correct run-time library search path by also including the local
libraries directories. For example, shared objects are linked on ELF
platforms with "cc -Wl,-R/usr/pkg/lib -L/usr/pkg/lib", and not just
"cc -L/usr/pkg/lib" as before.
/usr/local/scripts and forces the scripts to be installed there if it
exists. We override this by explicitly setting "scriptdir" to
"${PREFIX}/bin". This should fix the problem noted in pkg/14050 by
Brian Stark <bpstark@pacbell.net>.
problem reported in pkg/13663 by John Klos <john@sixgirls.org> where on
older (pre-current) NetBSD/vax, <ieeefp.h> exists but <machine/ieeefp.h>
doesn't, which was broken since <ieeefp.h> included <machine/ieeefp.h>.
include:
- Re-adding ${LOCALBASE}/include and ${LOCALBASE}/lib to the local compiler
search paths,
Other changes include:
- Migrating the setting to not install man3 pages from patch-ab into the
package Makefile so that they aren't installed across all pkgsrc platforms.
- Better document SYSLIBPATH.${OPSYS}.
perl mess I created a year ago and making this a vanilla perl installation
again, and explicitly setting the system library path so that /usr/local/*
doesn't appear anywhere.
The installed perl library now also includes CGI.pm-2.752. The www/p5-CGI
package installs in to ${PERL5_SITEARCH} so there is no conflict with the
"standard" CGI.pm.
it is updated not to have the perl-mk dependency.
This braindead nature of pkgsrc to register all dependencies recursively
into binary pkgs *will* be fixed.
to install things like "open.3" and "lib.3" which confuse users. Perl
ships with a documentation tool, "perldoc", for this purpose; create a
MESSAGE indicating that it should be used instead. (Perl still installs
command line program manual pages in man1.)
* Integrate bsd.perl.mk into the perl5-base build where it should have been
from the beginning. The separate perl-mk pkg makes binary packages of
perl-mk completely useless[*]. Older perl builders will not break, since
<bsd.pkg.mk> contains fallback definitions that are evaluated at pkg
build time.
=====
[*] bsd.perl.mk is tightly bound to the version of perl that is installed.
The version name "perl-mk-1.1" is completely useless as a binary pkg,
since keeping multiple binary versions of perl on a FTP server means
that one of the perl-mk's will get clobbered.
However, putting the current pkgsrc PERL5_DIST_VERS in the perl-mk pkg
is also a problem, because that doesn't necessarily reflect the
installed version of perl. Snarfing the installed version at perl-mk
build time would be even uglier, since you could not then walk the tree
without perl being installed.
The cleanest solution is to integrate bsd.perl.mk into the perl5-base
pkg, and let those who have not upgraded perl yet use the runtime
definitions in <bsd.pkg.mk>.
the plugging of several memory leaks, fixes to the regular expression
engine, the addition of a Unicode character classes, better support for
64-bit platorms, and updates of many modules in the base Perl Library.
See perldelta.pod for more details.
Also update p5-Data-Dumper, p5-Devel-DProf, and p5-Devel-Peek to the
latest versions distributed with the perl-5.6.1 sources, and libperl to
5.6.1 to match the perl package.
included in the perl executable. We need this to make the upcoming
xerces-perl package working.
This hack should be made obsolete by gcc-3.0, which will have a libgcc.so.
See http://mail-index.netbsd.org/tech-pkg/2001/04/07/0000.html for more details
