pkgsrc - [no description]

Age	Commit message (Collapse)	Author	Files	Lines
2006-07-14	Add a "bootstrap-register" target used specially by the bootstrap script	jlam	1	-1/+10
	to register packages that were installed by the bootstrap script.
2006-07-13	* Add a new stage "bootstrap-depends" that happens before all other	jlam	1	-4/+3
	stages, and that installs dependencies listed in BOOTSTRAP_DEPENDS. The bootstrap-depends step works just like the normal depends step and honors the value of DEPENDS_TARGET. It's now possible to add dependencies solely to facilitate fetching the distfiles, e.g. BOOTSTRAP_DEPENDS+= curl-[0-9]:../../www/curl Teach the tools framework about ":bootstrap" as a tools modifier which indicates the tool should be added as a dependency via BOOTSTRAP_DEPENDS. * Add "digest" to the tools framework. * Use USE_TOOLS+=digest:bootstrap to force pkgsrc to install digest before anything else. Get rid of unused "uptodate-digest" target and related digest version-checking code. * Finish the refactoring work: split checksum-related code out of bsd.pkg.mk and into pkgsrc/mk/checksum and replace the "checksum" target command list with a script that does all the real work. * Make DIGEST_ALGORITHMS and PATCH_DIGEST_ALGORITHM into private variables by prepending them with an underscore. Also, rename _PATCH_DIGEST_ALGORITHM to _PATCH_DIGEST_ALGORITHMS and adjust the makepatchsum target to allow that variable to contain a list of algorithms, all of which are used when creating the patch checksums for ${DISTINFO_FILE}.
2006-07-07	Rename <phase>_COOKIE variables to _COOKIE.<phase>. These are private	jlam	3	-19/+19
	variables so there are no user-visible changes. This change just makes it a little easier to write for loops.
2006-07-07	Make configure, install, and package barrier-aware even if NO_CONFIGURE,	jlam	1	-2/+4
	NO_INSTALL, or NO_PACKAGE are defined.
2006-07-06	The cookie files are indirectly made using *-cookie targets, so verify	jlam	1	-1/+3
	that they are never being created more than once by inserting a check into the *-cookie targets.
2006-07-05	Flatten out recursive makes into a single re-invocation of make by	jlam	3	-16/+28
	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".
2006-07-05	Make the check-vulnerable target more self-sufficient, by moving some	jlam	2	-8/+9
	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.
2006-06-14	Insert cookie checks into the "real-install" and "real-package" targets,	jlam	1	-1/+3
	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.
2006-06-10	Restore missing ${SETENV} ${BUILD_ENV} that was dropped during the initial	jlam	1	-2/+2
	package system flavors commit.
2006-06-09	Introduce the capability to gather all the warnings and errors that	jlam	1	-1/+2
	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.
2006-06-08	If the install cookie file exists, then we don't need to do anything.	jlam	1	-8/+23
	Also, move the interactive check into a separate target as a prelude to removing the recursive make for invoking "real-install".
2006-06-07	1.) Remove all instances of '@${WARNING_MSG} "Warning: ...' which resulted	tron	1	-6/+6
	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".
2006-06-06	Move some variable definitions out of bsd.prefs.mk and back into	jlam	1	-4/+4
	bsd.pkg.mk. They didn't actually need to be defined in bsd.prefs.mk, just somewhere before the "main" bsd.<phase>.mk files were included. This moves some conditional (?=) definitions back into bsd.pkg.mk so they won't conflict with any conditional definitions in package Makefiles. This should fix the "checksum" problems in lang/php-gd as noted here: http://mail-index.netbsd.org/pkgsrc-users/2006/06/05/0012.html where EXTRACT_SUFX had the wrong value due to the order in while *.mk files were included.
2006-06-06	Remove trailing blank line.	jlam	1	-2/+1

2006-06-05	Use PHASE_MSG, STEP_MSG, WARNING_MSG, and ERROR_MSG in place of ECHO_MSG	jlam	3	-18/+18
	in various places.
2006-06-05	Allow overrides of the public targets, e.g. "install", "package", etc.	jlam	4	-4/+16
	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.
2006-06-05	Move definitions for UPDATE_TARGET and DEPENDS_TARGET closer to where	jlam	1	-3/+3
	they are used. Also, move UPDATE_RUNNING into the install module where it is used, and make it "private" by prepending with an underscore.
2006-06-03	First pass at implementing support for package system flavors other	jlam	5	-0/+510
	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-05-21	Move mk/install to mk/pkginstall to better reflect the contents (the	jlam	18	-3646/+0
	pkginstall framework).
2006-05-21	Avoid a difference in shell implementation between IRIX 5.3 and newer	jlam	1	-2/+2
	UNIX systems which caused recursive script invocations to not work. Patch from Georg Schwarz in private email.
2006-05-10	Fix missing quotes that were causing the group and user existence checks	jlam	1	-3/+3
	to break.
2006-05-01	Use the meta-data directory as the location for all temporary files	jlam	6	-90/+111
	used by the various scriptlets. Also, consistently use the idiom of creating a temporary directory with mode 700 and creating temporary files underneath that directory to avoid race conditions.
2006-04-29	Ensure that @VAR@ placeholders in usergroupfuncs are properly substituted	jlam	1	-3/+3
	for by running it through a separate FILES_SUBST_SED filter. This fixes the case where the user wasn't being created if USERGROUP_PHASE was defined.
2006-04-29	Always remove the intermediate files, even if the +USERGROUP script	jlam	1	-6/+10
	determines the users and/or groups don't exist. This makes "make clean" work properly for non-root users.
2006-04-29	Remove the test file in all exit conditions.	jlam	3	-9/+9

2006-04-29	Allow for just-in-time su when creating users and groups if	jlam	1	-5/+13
	USERGROUP_PHASE is defined.
2006-04-27	Use a better default user comment if none is specified -- if the username	jlam	3	-6/+18
	matches ${PKGBASE}, then use "${PKGBASE} user", otherwise we use "${PKGBASE} $user user".
2006-04-26	Allow a package to specify the ownership and permission on	jlam	1	-3/+15
	${PKG_SYSCONFDIR} if PKG_SYSCONFSUBDIR is defined and non-empty. A package may now set PKG_SYSCONFDIR_PERMS to an "owner group mode" triplet, which defaults to "${ROOT_USER} ${ROOT_GROUP} 755".
2006-04-25	Rename the test directory to a more suggestive name.	jlam	2	-4/+4

2006-04-25	Modify the DIRS line format to match the FILES one, where the mode	jlam	2	-29/+42
	precedes the user and group.
2006-04-25	Use colons as separators instead of slashes on the off-chance that "/"	jlam	2	-27/+27
	is used in either the user or group name due to some bizarro set of circumstances.
2006-04-25	First try at fixing a deficiency in the package +INSTALL scripts,	jlam	5	-24/+263
	where they don't verify that any pre-existing config files and directories have the correct permissions. For example, if you are upgrading a package to a newer version and the config files and directories used by the package need to have different permissions than in previous versions of the package, then the new package may fail to work because it can't access pre-existing files and directories. This commit improves on this by doing the following: (1) Teach the +FILES and +DIRS scriptlets two new actions "PERMS" and "CHECK-PERMS". "PERMS" fixes permissions on existing files and directories. "CHECK-PERMS" will verify those same bits and warn the user when they are wrong. The "CHECK-PERMS" actions for the two scriptlets are run immediately after the "ADD" actions. (2) Add a new variable PKG_CONFIG_PERMS that controls whether the "PERMS" action will automatically fix permissions. PKG_CONFIG_PERMS is only consulted if PKG_CONFIG is "yes". PKG_CONFIG_PERMS can be set in the shell environment when running pkg_add, e.g.: export PKG_CONFIG=yes export PKG_CONFIG_PERMS=yes pkg_add /path/to/binary/package.tgz The default value of PKG_CONFIG_PERMS embedded into the +INSTALL script may also be set in /etc/mk.conf. This value defaults to "no", so that by default, the +INSTALL script will not modify or destroy any existing configuration files or directories. The +INSTALL script will now always warn you if there are files or directories whose permissions differ from what the package is expecting to use, and if PKG_CONFIG_PERMS is set to "yes", then it will go ahead and fix those permissions for you automatically.
2006-04-24	Fix typos in comments, noted by Yoshito Komatsu in private email.	jlam	3	-6/+6

2006-04-24	Fix {group,user}_exists functions when the numeric ID is not set. Fix	jlam	3	-9/+27
	provided in PR pkg/33346 by Yoshito Komatsu.
2006-04-23	Add two new capabilities to the pkginstall framework:	jlam	6	-70/+470
	(1) Allow specifying the numeric UID and GID for users and groups in /etc/mk.conf by setting PKG_UID.<user> and PKG_GID.<group> to those values. If these values are specified, then the +USERGROUP script will verify that existing users and groups match the requested UIDs and GIDs for the package, and otherwise create them with these UIDs and GIDs. For example: PKG_UID.courier= 10001 PKG_GID.mail= 6 In this example, the courier-authlib binary package will be created to use uid 10001 for the "courier" user and gid 6 for the "mail" group. (2) Allow a package to request that users and groups be created prior to configuring or building a package by setting USERGROUP_PHASE to "configure" or "build". Because the reason for this is typically to hardcode the UIDs and GIDs of requested users and groups directly into the package's executables, these hardcoded values will be automatically determined and put into the +USERGROUP script. For example: USERGROUP_PHASE= configure PKG_GROUPS= qmail nofiles PKG_USERS+= qmaill:nofiles PKG_USERS+= qmailq:qmail In this example, the users and groups are created before the configure phase when building qmail, and the qmail binary package's +INSTALL script will try to create (or verify) users and groups with the same UIDs and GIDs that were used during the build. As part of these changes, the format for PKG_USERS and PKG_GROUPS has changed -- the optional parts of the corresponding entries are no longer used and cannot be specified. Instead, the following variables should be set: PKG_GID.<group> is the group's numeric GID. PKG_UID.<user> is the user's numeric UID. PKG_GECOS.<user> is the user's description. PKG_HOME.<user> is the user's home directory. PKG_SHELL.<user> is the user's login shell. A separate commit will follow which will fix all packages that set PKG_USERS and PKG_GROUPS to use the new syntax and variables.
2006-04-16	Now that all info file entries have been pushed from INFO_FILES into	jlam	1	-12/+3
	the PLISTs, drop support for listing info files in INFO_FILES. The INFO_FILES variable is now strictly defined/undefined.
2006-04-12	Better error-checking in the +INFO_FILES scriptlet:	jlam	1	-34/+46
	(1) Don't claim to be adding and removing the info file if it does exist at all. (2) Always try to create and remove the directory containing the "dir" index file to avoid failures.
2006-04-06	Resurrect INFO_DIR for another purpose -- if defined, it sets the	jlam	2	-13/+26
	directory containing the "dir" file that is updated. This allows packages to install info files in one place but update the dir file in a separate location.
2006-03-20	* Creates a new variable PKGINFODIR (named similarly to PKGMANDIR)	jlam	1	-10/+23
	that is a purely user-settable variable to represent the relative path under ${PREFIX} where info files are stored and "dir" files are managed. PKGINFODIR defaults to "info". INFO_DIR still works, but will be obsoleted after the 2006Q1 branch. * Modify GNU_CONFIGURE_INFODIR to only honor ${PKGINFODIR} if the package installs directly into ${PREFIX} and not some subdirectory under ${PREFIX}. This fixes packages that don't really honor $(infodir) all that well, and also avoids PLIST problems relating to directory removal for those packages. * Since the majority of Emacs Lisp packages use GNU_CONFIGURE, just set GNU_CONFIGURE_INFODIR directly to ${EMACS_INFOPREFIX}, which is the Emacs-distro-specific location for info files. Also pass EMACS_INFOPREFIX through PLIST_SUBST for PLIST substitution. * INFO_FILES should be defined if the package installs info files. If the info files are not listed in the PLIST, then INFO_FILES must list the filenames for the info files installed by the package, which are assumed to be located in ${PREFIX}/${PKGINFODIR}. * The plist module can now better detect info files listed in PLISTs and exports a command to the pkginstall module to append info file names to the +INFO_FILES scriptlet at install-time. * The print-PLIST target is updated to properly list info files in the auto-generated PLIST. * The check-files code is updated to skip all "dir" Info database files.
2006-03-19	Modify the INSTALL script to allow for selective unpacking of a scriptlet.	jlam	9	-26/+31

2006-03-17	Ensure that we invoke a brand new make when creating the INSTALL/DEINSTALL	jlam	1	-5/+6
	and rc.d scripts so that we source the latest makevars.mk file and get the latest set of cached variables. This fixes problems where BUILDLINK_PREFIX.* wasn't being expanded correctly when substituting into an INSTALL script.
2006-03-15	Always run the pkginstall framework targets to generate the	jlam	1	-3/+25
	INSTALL/DEINSTALL and rc.d scripts, regardless of whether NO_BUILD is defined or not. We do this by renaming the main "build" target to "_build", and creating a new "build" target that has "_build" and "pkginstall" as dependencies. This allows the "build" and "install" targets to be consecutive, so no changes in behavior are visible to the user. Because the pkginstall targets are no longer run within the protection of the locks during the build phase, we need to manage locking within a new "pkginstall" target.
2006-03-15	Rototill of how the various template parts of the INSTALL and DEINSTALL	jlam	14	-261/+283
	scripts are generated. The various scriptlets in pkgsrc/mk/install are now full templates that can be combined to form the INSTALL and DEINSTALL scripts. All of the templates have either leading or trailing blank lines so that when they are concatentated, the full INSTALL and DEINSTALL scripts will still be easy to read. All of the generated template sources for the INSTALL and DEINSTALL scripts are now stored in ${WRKDIR}/.pkginstall for local consistency and have been renamed so that they are not dot-files. The "data" for the +* scriptlets are now generated in a separate step and instead of being appended to the unpacked scriptlet are now appended to the INSTALL script itself. When the scriptlets are unpacked, the corresponding data lines for each scriptlet are pulled out of the INSTALL script and put into the unpacked scriptlets. This makes it easy to append more data lines during the install phase without needing to regenerate the INSTALL script.
2006-03-14	Sync variable names in comments with recent changes to install framework.	tron	2	-4/+4

2006-03-14	Modify the pkginstall framework so that it manages all aspects of	jlam	1	-103/+113
	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.
2006-03-10	Cosmetic change: reorder some lines locally to make it easier for me	jlam	1	-13/+13
	to understand.
2006-03-10	Expose fewer knobs for a user to tweak by making more variables private.	jlam	1	-57/+53

2006-03-10	Don't define DEINSTALL_FILE or INSTALL_FILE if the corresponding *_SRC	jlam	1	-1/+5
	variables are empty.
2006-03-09	Make it safe to include bsd.pkginstall.mk directly in bsd.pkg.mk, and	jlam	2	-108/+101
	drop pkginstall.mk, which did the same thing. Also, rework some of the targets so that we avoid needing to inspect *_MEMBERS variables within make -- we defer the check to the shell code invoked by the targets. All changes are internal and don't affect existing packages in a visible way.
2006-03-09	Reimplement the info-file handling so that we use an +INFO_FILES	jlam	6	-41/+172
	scriptlet to manage the info-file registration. The new scriptlet's template is install/info-files. Remove obsolete texinfo.mk and install/install-info. No changes to package Makefiles are necessary -- the re-implementation is internal to pkgsrc infrastructure.