name which isn't correct, and the "Value of SrcDir" that is used is not
important to any pkgsrc user. Instead, let the pkgsrc infrastructure
print the package name.
possible to create the package file using a temporary file first, and if
everything has succeeded, to rename it to the real name. This time, I
tested it creating various binary packages and installing them
afterwards, so I'm pretty sure it works now.
it had severe consequences: pkg_create gets lots of information from the
filename into which the package is written. The extension decides what
compression to apply, and the basename gets recorded as the @name. This
part needs more work.
Noticed by stoned@.
everything went well, rename it to the real name. That way, it is less
likely that broken binary packages are created. It is a common
assumption that binary package files, if they exist, are usable.
An example for a broken binary package is security/sudo-1.6.9p10, in
which sbin/visudo wasn't readable when creating the package as an
unprivileged user.
- USE_CROSS_COMPILATION activates it, CROSS_DESTDIR specifies root of
the target filesystem
- derive _CROSS_DESTDIR from CROSS_DESTDIR or MAKEOBJDIR
- buildlink3.mk prefixes the files to symlink with _CROSS_DESTDIR
- compiler/gcc.mk knows about the target prefix (e.g. i386--netbsdelf)
- PKG_DBDIR is prefixed with _CROSS_DESTDIR
- package-install and bin-install are not called with su
- install and strip are redirected to the tool version
- links for the target specific ar, as, ld, nm, objdump, ranlib and
strip are added
- compiler wrapper detect if linking is requested or not
- special command sinks for CPP and CC/CXX add the cross-compile magic:
- modify include dirs to get the target /usr/include
- modify linker dirs and runpath to use target /usr/lib at link time,
but keep correct rpath entries
Supported-by: Google SoC 2007
Basic tests by he@ on Sparc. Review from jlam@.
are identical. For DESTDIR builds, the package is not installed to
PREFIX as part of the build, so package-install does exactly that after
package is done. Change bin-install to call package-install.
Packages may set PKG_DESTDIR_SUPPORT to either "destdir" or
"user-destdir" to flag support for this, following the same
rules as PKG_INSTALLATION_TYPES (e.g. define before first include
of bsd.prefs.mk).
The user activates it via USE_DESTDIR. When set to "yes",
packages with "user-destdir" are handled as "destdir".
The installation of the package will not go to ${LOCALBASE},
but a subdirectory of ${WRKDIR} instead. pre/post install scripts are
not run and the package is not registered either. A binary package
can be created instead to be installed normally with pkg_add.
For "user-destdir" packages, everything is run as normal user and
ownership is supposed to be correctled by pkg_create later. Since
the current pkg_install code uses pax and it doesn't allow overwriting
owners, this does not work yet.
For "destdir" packages, installation, packaging and cleaning is run as
root.
This commit does not change the handling of DEPENDS_TARGET or
bin-install to allow recursive usage.
since it is user settable and most of the time set by the user.
X11BASE follows the same reasons. For staged installations, we don't
want to register the package directly, so there's no need to prefix
PKG_DBDIR either.
than pkgsrc's current one. This is an important lead-up to any project
that redesigns the pkg_* tools in that it doesn't tie us to past design
(mis)choices. This commit mostly deals with rearranging code, although
there was a considerable amount of rewriting done in cases where I
thought the code was somewhat messy and was difficult to understand.
The design I chose for supporting multiple package system flavors is
that the various depends, install, package, etc. modules would define
default targets and variables that may be overridden in files from
pkgsrc/mk/flavor/${PKG_FLAVOR}. The default targets would do the
sensible thing of doing nothing, and pkgsrc infrastructure would rely
on the appropriate things to be defined in pkgsrc/mk/flavor to do the
real work. The pkgsrc/mk/flavor directory contains subdirectories
corresponding to each package system flavor that we support. Currently,
I only have "pkg" which represents the current pkgsrc-native package
flavor. I've separated out most of the code where we make assumptions
about the package system flavor, mostly either because we directly
use the pkg_* tools, or we make assumptions about the package meta-data
directory, or we directly manipulate the package meta-data files, and
placed it into pkgsrc/mk/flavor/pkg.
There are several new modules that have been refactored out of bsd.pkg.mk
as part of these changes: check, depends, install, package, and update.
Each of these modules has been slimmed down by rewriting them to avoid
some recursive make calls. I've also religiously documented which
targets are "public" and which are "private" so that users won't rely
on reaching into pkgsrc innards to call a private target.
The "depends" module is a complete overhaul of the way that we handle
dependencies. There is now a separate "depends" phase that occurs
before the "extract" phase where dependencies are installed. This
differs from the old way where dependencies were installed just before
extraction occurred. The reduce-depends.mk file is now replaced by
a script that is invoked only once during the depends phase and is
used to generate a cookie file that holds the full set of reduced
dependencies. It is now possible to type "make depends" in a package
directory and all missing dependencies will be installed.
Future work on this project include:
* Resolve the workflow design in anticipation of future work on
staged installations where "package" conceptually happens before
"install".
* Rewrite the buildlink3 framework to not assume the use of the
pkgsrc pkg_* tools.
* Rewrite the pkginstall framework to provide a standard pkg_*
tool to perform the actions, and allowing a purely declarative
file per package to describe what actions need to be taken at
install or deinstall time.
* Implement support for the SVR4 package flavor. This will be
proof that the appropriate abstractions are in place to allow
using a completely different set of package management tools.
