Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Oct 2, 2012
  1. Fixes for target "repackage"

    cheusov authored
Commits on May 27, 2012
  1. "rebuild" and "retest" targets were added (by analogy with "reinstall").

    cheusov authored
    rebuild is a special target to re-run the build target.
    retest is a special target to re-run the test target.
Commits on Oct 15, 2011
  1. Rename "flavor" to "pkgformat".

    reed authored
    This is from Anton Panev's GSoC 2011 project to add RPM and DPKG
    support to pkgsrc. (I am not adding that further support in this
    commit.)
    
    This is just a rename of the existing functionality. Now it will
    be easy to test the GSoC work by simply putting in a single
    directory (such as "rpm" or "deb"). See
    http://addpackageforma.sourceforge.net/ for some details.
    
    This is from Anton's CVS, but I made some minor changes:
    
    - changed plural pkgformats to singular pkgformat (to be consistent)
    
    - fixed a few places (in comments) that were missed
    
    - catch up on some additions to flavor not in the pkgforma cvs:
    PKGSRC_SETENV and _flavor-destdir-undo-replace and
    undo-destdir-replace-install.
Commits on Mar 8, 2010
Commits on Feb 25, 2010
Commits on Feb 24, 2010
  1. Rename the install phase to stage-install. Introduce a new install

    joerg authored
    target that defaults to either stage-install or package-install,
    depending on whether DESTDIR support is active and supported by the
    package or not.
Commits on Jun 9, 2009
  1. Add support for using USE_DESTDIR=yes and replace together.

    joerg authored
    Based on the patch send to tech-pkg in 2008, but less intrusive.
Commits on Apr 9, 2009
  1. Remove support for NO_PACKAGE.

    joerg authored
Commits on Mar 17, 2009
  1. Replaced _PKG_SILENT and _PKG_DEBUG with RUN.

    rillig authored
Commits on Jan 4, 2008
  1. Made the .include directives simpler, since the directory of the

    rillig authored
    including file is always the first in the search path.
Commits on Mar 8, 2007
Commits on Oct 9, 2006
  1. Main infrastructure for DESTDIR support.

    joerg authored
    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.
  2. Add two variables to control whether make package and make clean

    joerg authored
    are run with elevated privileges. Remove MAKE_PACKAGE_AS_ROOT
    for now, since it is not sure whether the functionality in the current
    form will stay and developers should spend time on the destdir support
    instead.
Commits on Oct 8, 2006
  1. Added a new variable MAKE_PACKAGE_AS_ROOT that controls whether the

    rillig authored
    package needs to be packed by root or whether the unprivileged user can
    do that as well. Most packages don't need root privileges, but the
    default value is nevertheless "yes" to not break too many existing
    packages.
    
    pkgsrc users are encouraged to add the following to their mk.conf:
    
        MAKE_PACKAGES_AS_ROOT?= no
    
    The "?=" operator here is important because after the testing phase,
    this variable is only intended to be set by packages. If "=" would be
    used instead, packages could not override the value.
Commits on Jul 22, 2006
  1. Modify the barrier so that we always invoke the recursive make process

    jlam authored
    when passing through the barrier.  This ensures the PATH (passed via
    PKGSRC_MAKE_ENV) is correctly set for all phases after the barrier.
    
    This fixes a bug in "interactive" pkgsrc use, where if you have no
    work directory and type "make build && make install", then the "install"
    step does not have a PATH set to include all the wrapper and tools
    directories.
Commits on Jul 7, 2006
  1. Rename <phase>_COOKIE variables to _COOKIE.<phase>. These are private

    jlam authored
    variables so there are no user-visible changes.  This change just makes
    it a little easier to write for loops.
  2. Make configure, install, and package barrier-aware even if NO_CONFIGURE,

    jlam authored
    NO_INSTALL, or NO_PACKAGE are defined.
Commits on Jul 6, 2006
  1. The cookie files are indirectly made using *-cookie targets, so verify

    jlam authored
    that they are never being created more than once by inserting a check
    into the *-cookie targets.
  2. The "replace" target does conceptually the same thing as the "install"

    jlam authored
    target in that it installs the currently-built software into the
    filesystem.  In that case where "replace" is specified as a target on
    the command line, make "replace" and not "install" be the source target
    for "package".
    
    Also, place the "replace" target between the "install" and "package"
    targets in _BARRIER_POST_TARGETS as it should be legal to do those
    steps in that order (but not in another order).
    
    These changes make the following work:
    
    	make replace package
    
    In this example, the currently installed package will be replaced and
    the newly-installed software will be packaged, all within the same
    make process.
Commits on Jul 5, 2006
  1. Flatten out recursive makes into a single re-invocation of make by

    jlam authored
    introducing the concept of a "barrier".  We separate the user-invokable
    targets into ones that must happen before the barrier, and ones that
    must happen after the barrier.  The ones that happen after the barrier
    are run in a sub-make process.  In this case, the targets that must
    be run after the barrier are from the "wrapper" step and beyond.  We
    rewrite the various "flow" targets, e.g. wrapper, configure, build,
    etc., so that they of the right form to use the barrier target.
    
    This now completely removes the concept of PKG_PHASE from pkgsrc.  It
    is replaced with the concept of "before" and "after" the barrier, and
    this state can be checked by testing for the existence of the barrier
    cookie file.  Because we've removed most of the recursive makes, there
    is now nowhere to hook the PKG_ERROR_HANDLER.* commands, so remove
    them for now.
    
    As part of this commit, put back the logic that conditionalized the
    sources for the various cookie files.  Because the sources are all
    "phony" targets, they were always run, regardless of whether or not
    the cookie file already existed.  Now, if a cookie file exists, then
    that entire phase associated with that cookie file is skipped.
    
    Lastly, fix a thinko in configure/bsd.configure.mk where setting
    NO_CONFIGURE in a package Makefile would manage to skip the "wrapper"
    step altogether.  Fix this by correctly noting "wrapper" and not
    "patch" as the preceding step to "configure".
  2. Make the check-vulnerable target more self-sufficient, by moving some

    jlam authored
    of the logic from fetch/fetch.mk into flavor/pkg/check.mk, so that
    check-vulnerable can be used as a source target.
    
    Make check-vulnerable a source target for every phase of the build
    workflow, which ensures that it is always run if the user starts a
    new phase from the command line.
    
    Fix the cookie-generation targets so that they don't append, only
    overwrite to the cookie file.  This works around potential problems
    due to recursive makes.
    
    Move the cookie checks so that they surround the corresponding phase
    target.  The presence of the cookie should now inform the make process
    to avoid doing any processing of phases that occur before the phase
    corresponding to the cookie.
Commits on Jun 18, 2006
Commits on Jun 14, 2006
  1. Insert cookie checks into the "real-install" and "real-package" targets,

    jlam authored
    which are invoked in recursive make calls for the "install" and
    "package" targets respectvely.  These recursive make calls prevent
    the top-level make from seeing all of the targets and computing a full
    dependency graph, so it becomes possible for some targets to be invoked
    more than once.  This change passes enough information along to the
    recursive make calls and ensures that the source targets for the real-*
    targets are only invoked once.
Commits on Jun 10, 2006
  1. Restore missing ${SETENV} ${BUILD_ENV} that was dropped during the in…

    jlam authored
    …itial
    
    package system flavors commit.
Commits on Jun 9, 2006
  1. Introduce the capability to gather all the warnings and errors that

    jlam authored
    are generated for a target and output them all at once at the conclusion
    of the target's invocation.  The implementation is in bsd.pkg.error.mk,
    which defines a macro target "error-check" that will print out any
    non-empty warning and error files in ${WARNING_DIR} and ${ERROR_DIR}
    and exit appropriately if there were errors.
    
    Convert some targets that were just long sequences of ${ERROR_MSG} or
    ${WARNING_MSG} within a single shell statement to use the new delayed
    error output via error-check.
    
    Modify the compiler "fail" wrappers for C++ and Fortran to be less
    verbose during invocation.  Instead collect the warnings and only
    print them at the end of the completed phase, e.g. after "configure"
    and/or "build" completes.
Commits on Jun 8, 2006
  1. If the package cookie file exists, then we don't need to do anything.

    jlam authored
    Also, make use of a _REAL_PACKAGE_TARGETS variable just to make all
    of the code between the different stages more uniform.
Commits on Jun 7, 2006
  1. 1.) Remove all instances of '@${WARNING_MSG} "Warning: ...' which res…

    tron authored
    …ulted
    
        in error message like 'WARNING: Warning: ...'.
    2.) Replace "WARN_MSG" with "WARNING_MSG" which makes the "make package"
        target work again for restricted packages like "acroread7".
Commits on Jun 5, 2006
  1. Allow overrides of the public targets, e.g. "install", "package", etc.

    jlam authored
    if PKG_SKIP_REASON or PKG_FAIL_REASON is defined.  This commit adds
    !target(...) guards around those target definitions to avoid "duplicate
    target definition" warnings.
Commits on Jun 3, 2006
  1. First pass at implementing support for package system flavors other

    jlam authored
    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.
Something went wrong with that request. Please try again.