| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
to santise environment
|
|
|
|
|
|
names to indicate that they are purely private to flavor/pkg.
|
|
contains files that are generated during the "install" phase. This
should fix the problem where PLIST modifications were ignored if the
PLIST was modified between a "make deinstall" and a "make reinstall".
|
|
trace the dependency information. This is computed and stored in
.depends directly now before anything else is done. The output is locked
and the locking is supposed to work before the bootstrap-depends are
installed.
Add a new hook for flavors after all dependencies are added and before
the depends-cookie is created. Use this to compute which package is used
to fulfill each dependency and store it in .rdepends. Adjust
register-dependencies and some other places to use this information
directly instead of recomputing it all the time.
The code to list all dependencies and to recursively install missing
ones is moved to a separate shell script. This makes it easier to
understand what is going on and extend them later.
Change the calling of pkg_create to prepend the dependencies directly to
the passed-in PLIST and not via -P and -T. This is in preperation of
changing the way they are stored in the packages.
Discussed with, recieved minor disagreement about install-dependencies,
but otherwise OKed by jlam.
|
|
Split check-vulnerable into a general an a flavor-specific part, for
consistence with all the other targets.
|
|
variables so there are no user-visible changes. This change just makes
it a little easier to write for loops.
|
|
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.
|
|
wasn't used to identify a ``phase'', as defined in the pkgsrc guide.
|
|
|
|
|
|
resolved in much the same manner as variables set using :=. PKGNAME
could be set after including bsd.pkg.mk (which is poor form), and it's
too close to the pkgsrc-2006Q2 branch to fix that all over pkgsrc at
this time). This fixes building shells/static-bash2.
|
|
in various places.
|
|
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.
|
