2010-02-10 00:02:13 +01:00
|
|
|
# $NetBSD: package.mk,v 1.20 2010/02/09 23:02:13 joerg Exp $
|
First pass at implementing support for package system flavors other
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.
2006-06-04 01:11:42 +02:00
|
|
|
|
2010-02-10 00:02:13 +01:00
|
|
|
.if defined(PKG_SUFX)
|
|
|
|
|
WARNINGS+= "PKG_SUFX is deprecated, please use PKG_COMPRESSION"
|
|
|
|
|
. if ${PKG_SUFX} == ".tgz"
|
|
|
|
|
PKG_COMPRESSION= gzip
|
|
|
|
|
. elif ${PKG_SUFX} == ".tbz"
|
|
|
|
|
PKG_COMPRESSION= bzip2
|
|
|
|
|
. else
|
|
|
|
|
WARNINGS+= "Unsupported value for PKG_SUFX"
|
|
|
|
|
. endif
|
|
|
|
|
.endif
|
First pass at implementing support for package system flavors other
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.
2006-06-04 01:11:42 +02:00
|
|
|
PKG_SUFX?= .tgz
|
|
|
|
|
PKGFILE?= ${PKGREPOSITORY}/${PKGNAME}${PKG_SUFX}
|
|
|
|
|
PKGREPOSITORY?= ${PACKAGES}/${PKGREPOSITORYSUBDIR}
|
|
|
|
|
PKGREPOSITORYSUBDIR?= All
|
|
|
|
|
|
|
|
|
|
######################################################################
|
|
|
|
|
### package-check-installed (PRIVATE, pkgsrc/mk/package/package.mk)
|
|
|
|
|
######################################################################
|
|
|
|
|
### package-check-installed verifies that the package is installed on
|
|
|
|
|
### the system.
|
|
|
|
|
###
|
|
|
|
|
.PHONY: package-check-installed
|
|
|
|
|
package-check-installed:
|
2007-09-07 19:01:10 +02:00
|
|
|
${RUN} ${PKG_INFO} -qe ${PKGNAME} \
|
|
|
|
|
|| ${FAIL_MSG} "${PKGNAME} is not installed."
|
First pass at implementing support for package system flavors other
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.
2006-06-04 01:11:42 +02:00
|
|
|
|
|
|
|
|
######################################################################
|
|
|
|
|
### package-create (PRIVATE, pkgsrc/mk/package/package.mk)
|
|
|
|
|
######################################################################
|
|
|
|
|
### package-create creates the binary package.
|
|
|
|
|
###
|
|
|
|
|
.PHONY: package-create
|
|
|
|
|
package-create: package-remove ${PKGFILE} package-links
|
|
|
|
|
|
|
|
|
|
_PKG_ARGS_PACKAGE+= ${_PKG_CREATE_ARGS}
|
2010-02-10 00:02:13 +01:00
|
|
|
_PKG_ARGS_PACKAGE+= -F ${PKG_COMPRESSION}
|
2006-10-09 14:25:44 +02:00
|
|
|
.if ${_USE_DESTDIR} == "no"
|
2006-10-06 16:51:36 +02:00
|
|
|
_PKG_ARGS_PACKAGE+= -p ${PREFIX}
|
2006-10-09 14:25:44 +02:00
|
|
|
.else
|
|
|
|
|
_PKG_ARGS_PACKAGE+= -I ${PREFIX} -p ${DESTDIR}${PREFIX}
|
2007-08-03 16:03:39 +02:00
|
|
|
. if ${_USE_DESTDIR} == "user-destdir"
|
|
|
|
|
_PKG_ARGS_PACKAGE+= -u ${REAL_ROOT_USER} -g ${REAL_ROOT_GROUP}
|
|
|
|
|
. endif
|
2006-10-09 14:25:44 +02:00
|
|
|
.endif
|
First pass at implementing support for package system flavors other
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.
2006-06-04 01:11:42 +02:00
|
|
|
.if ${PKG_INSTALLATION_TYPE} == "pkgviews"
|
|
|
|
|
_PKG_ARGS_PACKAGE+= -E
|
|
|
|
|
.endif
|
|
|
|
|
|
|
|
|
|
${PKGFILE}: ${_CONTENTS_TARGETS}
|
2007-09-07 19:01:10 +02:00
|
|
|
${RUN} ${MKDIR} ${.TARGET:H}
|
2008-01-23 15:07:07 +01:00
|
|
|
@${STEP_MSG} "Creating binary package ${.TARGET}"
|
2008-01-05 23:06:20 +01:00
|
|
|
${RUN} tmpname=${.TARGET:S,${PKG_SUFX}$,.tmp${PKG_SUFX},}; \
|
|
|
|
|
if ${PKG_CREATE} ${_PKG_ARGS_PACKAGE} "$$tmpname"; then \
|
|
|
|
|
${MV} -f "$$tmpname" ${.TARGET}; \
|
|
|
|
|
else \
|
|
|
|
|
exitcode=$$?; ${RM} -f "$$tmpname"; exit $$exitcode; \
|
|
|
|
|
fi
|
First pass at implementing support for package system flavors other
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.
2006-06-04 01:11:42 +02:00
|
|
|
|
|
|
|
|
######################################################################
|
|
|
|
|
### package-remove (PRIVATE)
|
|
|
|
|
######################################################################
|
|
|
|
|
### package-remove removes the binary package from the package
|
|
|
|
|
### repository.
|
|
|
|
|
###
|
|
|
|
|
.PHONY: package-remove
|
|
|
|
|
package-remove:
|
2007-09-07 19:01:10 +02:00
|
|
|
${RUN} ${RM} -f ${PKGFILE}
|
First pass at implementing support for package system flavors other
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.
2006-06-04 01:11:42 +02:00
|
|
|
|
|
|
|
|
######################################################################
|
|
|
|
|
### package-links (PRIVATE)
|
|
|
|
|
######################################################################
|
|
|
|
|
### package-links creates symlinks to the binary package from the
|
|
|
|
|
### non-primary categories to which the package belongs.
|
|
|
|
|
###
|
|
|
|
|
package-links: delete-package-links
|
|
|
|
|
.for _dir_ in ${CATEGORIES:S/^/${PACKAGES}\//}
|
2007-09-07 19:01:10 +02:00
|
|
|
${RUN} ${MKDIR} ${_dir_:Q}
|
|
|
|
|
${RUN} [ -d ${_dir_:Q} ] \
|
|
|
|
|
|| ${FAIL_MSG} "Can't create directory "${_dir_:Q}"."
|
|
|
|
|
${RUN} ${RM} -f ${_dir_:Q}/${PKGFILE:T}
|
|
|
|
|
${RUN} ${LN} -s ../${PKGREPOSITORYSUBDIR}/${PKGFILE:T} ${_dir_:Q}
|
First pass at implementing support for package system flavors other
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.
2006-06-04 01:11:42 +02:00
|
|
|
.endfor
|
|
|
|
|
|
|
|
|
|
######################################################################
|
|
|
|
|
### delete-package-links (PRIVATE)
|
|
|
|
|
######################################################################
|
|
|
|
|
### delete-package-links removes the symlinks to the binary package from
|
|
|
|
|
### the non-primary categories to which the package belongs.
|
|
|
|
|
###
|
|
|
|
|
delete-package-links:
|
2007-09-07 19:01:10 +02:00
|
|
|
${RUN} ${FIND} ${PACKAGES} -type l -name ${PKGFILE:T} -print \
|
|
|
|
|
| ${XARGS} ${RM} -f
|
First pass at implementing support for package system flavors other
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.
2006-06-04 01:11:42 +02:00
|
|
|
|
|
|
|
|
######################################################################
|
|
|
|
|
### tarup (PUBLIC)
|
|
|
|
|
######################################################################
|
|
|
|
|
### tarup is a public target to generate a binary package from an
|
|
|
|
|
### installed package instance.
|
|
|
|
|
###
|
|
|
|
|
_PKG_TARUP_CMD= ${LOCALBASE}/bin/pkg_tarup
|
|
|
|
|
|
|
|
|
|
.PHONY: tarup
|
|
|
|
|
tarup: package-remove tarup-pkg package-links
|
|
|
|
|
|
|
|
|
|
######################################################################
|
|
|
|
|
### tarup-pkg (PRIVATE)
|
|
|
|
|
######################################################################
|
|
|
|
|
### tarup-pkg creates a binary package from an installed package instance
|
|
|
|
|
### using "pkg_tarup".
|
|
|
|
|
###
|
|
|
|
|
tarup-pkg:
|
2007-09-07 19:01:10 +02:00
|
|
|
${RUN} [ -x ${_PKG_TARUP_CMD} ] || exit 1; \
|
First pass at implementing support for package system flavors other
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.
2006-06-04 01:11:42 +02:00
|
|
|
${SETENV} PKG_DBDIR=${_PKG_DBDIR} PKG_SUFX=${PKG_SUFX} \
|
|
|
|
|
PKGREPOSITORY=${PKGREPOSITORY} \
|
|
|
|
|
${_PKG_TARUP_CMD} ${PKGNAME}
|
2006-11-03 09:01:04 +01:00
|
|
|
|
|
|
|
|
######################################################################
|
|
|
|
|
### package-install (PUBLIC)
|
|
|
|
|
######################################################################
|
|
|
|
|
### When DESTDIR support is active, package-install uses package to
|
|
|
|
|
### create a binary package and installs it.
|
|
|
|
|
### Otherwise it is identical to calling package.
|
|
|
|
|
###
|
|
|
|
|
|
|
|
|
|
.PHONY: package-install real-package-install su-real-package-install
|
|
|
|
|
.if defined(_PKGSRC_BARRIER)
|
|
|
|
|
package-install: package real-package-install
|
|
|
|
|
.else
|
|
|
|
|
package-install: barrier
|
|
|
|
|
.endif
|
|
|
|
|
|
|
|
|
|
.if ${_USE_DESTDIR} != "no"
|
2007-08-02 20:19:31 +02:00
|
|
|
. if !empty(USE_CROSS_COMPILE:M[yY][eE][sS])
|
|
|
|
|
real-package-install: su-real-package-install
|
|
|
|
|
. else
|
2006-11-03 09:01:04 +01:00
|
|
|
real-package-install: su-target
|
2007-08-02 20:19:31 +02:00
|
|
|
. endif
|
2006-11-03 09:01:04 +01:00
|
|
|
.else
|
|
|
|
|
real-package-install:
|
|
|
|
|
@${DO_NADA}
|
|
|
|
|
.endif
|
|
|
|
|
|
|
|
|
|
su-real-package-install:
|
|
|
|
|
@${PHASE_MSG} "Install binary package of "${PKGNAME:Q}
|
2007-08-02 20:19:31 +02:00
|
|
|
.if !empty(USE_CROSS_COMPILE:M[yY][eE][sS])
|
|
|
|
|
@${MKDIR} ${_CROSS_DESTDIR}${PREFIX}
|
2007-08-15 15:20:57 +02:00
|
|
|
${PKG_ADD} -m ${MACHINE_ARCH} -I -p ${_CROSS_DESTDIR}${PREFIX} ${PKGFILE}
|
2007-08-02 20:19:31 +02:00
|
|
|
@${ECHO} "Fixing recorded cwd..."
|
|
|
|
|
@${SED} -e 's|@cwd ${_CROSS_DESTDIR}|@cwd |' ${_PKG_DBDIR}/${PKGNAME:Q}/+CONTENTS > ${_PKG_DBDIR}/${PKGNAME:Q}/+CONTENTS.tmp
|
|
|
|
|
@${MV} ${_PKG_DBDIR}/${PKGNAME:Q}/+CONTENTS.tmp ${_PKG_DBDIR}/${PKGNAME:Q}/+CONTENTS
|
|
|
|
|
.else
|
2009-10-31 13:22:59 +01:00
|
|
|
${RUN} case ${_AUTOMATIC:Q}"" in \
|
2009-02-13 12:30:07 +01:00
|
|
|
[yY][eE][sS]) ${PKG_ADD} -A ${PKGFILE} ;; \
|
|
|
|
|
*) ${PKG_ADD} ${PKGFILE} ;; \
|
|
|
|
|
esac
|
2007-08-02 20:19:31 +02:00
|
|
|
.endif
|
