| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
pkgsrc/emulator/compat* and pkgsrc/emulator/netbsd32_compat* packages
to provide the necessary shared libraries to run dynamically linked
NetBSD binaries from the days of yore.
* Add some additional compat* packages for completeness:
compat15, compat20, compat30
* Modify the compat* packages so that "compatNM" only provides files
that aren't in "NetBSD-N.(M+1)". For example, compat12 only provides
files that don't exist in NetBSD-1.3.x, compat13 only provides files
that don't exist in NetBSD-1.4.x, etc.
As a result, if you are running NetBSD-3.0/alpha and want to run a
1.3 dynamically linked binary, there is an automatic dependency
chain that causes the following packages to be installed:
compat13, compat14, compat15, compat16, compat20
There are some deviations from this dependency chain on platforms
that have changed executable formats, e.g. i386, m68, sparc, etc.
However, in general pkgsrc will require that you have the necessary
COMPAT_* options in your kernel to match the installed compat*
packages. This restriction is an artificial one imposed by pkgsrc,
but allows for a single set of distfiles to be used on all versions
of NetBSD.
* Provide compat* package support for every supported architecture
of NetBSD. Verily, it is now possible to run 1.2 binaries on
NetBSD-1.5.3/pc532 by installing the compat12 package from pkgsrc.
Rejoice, one and all!
* The netbsd32_compat* packages mirror the corresponding compat*
packages for use by sparc64 and x86_64 to allow running 32-bit
binaries with COMPAT_NETBSD32 kernel support. The "extras" packages
supply the additional shared libraries from the corresponding release
of NetBSD so that the set of files in /emul/netbsd32 will be complete.
* pkgsrc/emulators/compat_netbsd contains infrastructure files shared
by all of the compat* packages.
|
|
|
|
it will live with other "check" targets run after package installation.
Get rid of SHLIB_HANDLING, whose meaning had mutated over the years
from one thing to another. Currently, it is used to basically note
whether the system's "ldd" command can be usefully run on the package's
binaries and libraries. Rename this variable to CHECK_SHLIBS_SUPPORTED
for more clarity.
CHECK_SHLIBS is now a variable set exclusively by the user in /etc/mk.conf
to note whether the check for missing run-time search paths is performed
after a package is installed. It defaults to "no" unless PKG_DEVELOPER
is set.
|
|
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.
|
|
developer is officially maintaining the package.
The rationale for changing this from "tech-pkg" to "pkgsrc-users" is
that it implies that any user can try to maintain the package (by
submitting patches to the mailing list). Since the folks most likely
to care about the package are the folks that want to use it or are
already using it, this would leverage the energy of users who aren't
developers.
|
|
automatically detects whether we want the pkginstall machinery to be
used by the package Makefile.
|
|
example MAKE_ENV+=FOO=${BAR} is changed to MAKE_ENV+=FOO=${BAR:Q}. Some
other changes are outlined in
http://mail-index.netbsd.org/tech-pkg/2005/12/02/0034.html
|
|
NO_BUILD, USE_LIBTOOL.
|
|
|
|
|
|
PLIST.${MACHINE_ARCH:C/i[3-6]86/i386/g}
PLIST.${OPSYS}-${MACHINE_ARCH:C/i[3-6]86/i386/g}
and remove the package hack for MD PLIST files.
PLIST.* files renamed so we don't need the special handling for MACHINE32_ARCH.
Merge the PLIST.* files as much as possible into PLIST, so they only
contain the difference between the two archs which are only supported by
this package.
|
|
|
|
s/chmod/${CHMOD}/
|
|
USE_PKGINSTALL is "YES". bsd.pkg.install.mk will no longer automatically
pick up a INSTALL/DEINSTALL script in the package directory and assume that
you want it for the corresponding *_EXTRA_TMPL variable.
|
|
|
|
|
|
Should anybody feel like they could be the maintainer for any of thewe packages,
please adjust.
|
|
don't call install with multiple directory args.
|
|
of 32 bit 1.6 binaries for 64 bit platforms that support this (really
only sparc64.)
|
