the pkgsrc infrastructure. And the current infrastructure differs
enough from how it looked when the crosspkgtools was made, so a
somewhat different approach is needed.
the very slow jobs in x11 when other jobs are available for processing.
Some packages need up to 10min for pbulk-index on my build system and
the reorder reduces the overall scan time with 4 clients from 35min to
30min.
Discussed with jlam@.
INDEX and calling it directly. As the output is removed anyway, it
forced a full rescan on every "make search". Calling "make index" still
regenerates it all the time, but the other targets don't.
OK wiz@
PRs: 26442, 34207, 35266
- completely redo the code which decides on the machine architecture,
operating system, and operating system version for the binary packages.
The old way just used to directory names to take a guess. The new
way creates a cache file containing meta-data for all the binary packages
in each "All" directory. This cache file is consulted when generating
the lists of available binary packages. The meta-data is obtained with
pkg_info so it should always be correct even if you do something silly
like mix OS_VERSION or MACHINE_ARCH packages up in the same directory.
Among the benefits are: works when PACKAGES is not $PKGSRC/packages,
works with a more or less arbitrary subdirectory structure, works
when there are subdirectories for multiple operating systems.
This portion of the fix should address PR25390.
The cache files are only updated when the contents of an "All" directory
changes or if the cache file format changes. There is some room for
improving the updating of the cache files, but its not too bad the way
it is.
- fix up some of the awk code so that generadme.awk works with Solaris
nawk as well as NetBSD's nawk and gawk (for pre-2.0 systems).
- remove some "if ! foo" shell constructs to increase portability.
- be more consistent with what variables get passed to mkreadme from
make and which ones are determined automatically. Mostly this meant
moving stuff into mkreadme to make it easier to run it standalone.
as it's only used internally by bsd.prefs.mk.
* Make _PKGSRCDIR a public variable by renaming it to PKGSRCDIR.
Also, generate its value from ${_PKGSRC_TOPDIR} so it's less fragile
than the old method of stripping off the last two components of
${.CURDIR}. PKGSRCDIR may now be used after bsd.prefs.mk is defined.
* Change all references to _PKGSRCDIR to PKGSRCDIR.
don't descend into this directory for anything since these packages aren't
packages in the normal sense, since they're not expected to install or
package correctly.
List all packages that depend on a particular package; needs the INDEX file
Usage: 'make show-deps PKG=openssl'
PKG: name of the package
No make dependency on INDEX by purpose, since INDEX generation
right now happens too often (too much phoniness, I guess).
several orders of magnitude and 'make index' now takes 30 minutes or so
instead of several days on my test machine. The approach now is to take
one pass through every package and extract some key information including
the explicitly listed dependencies. After the data is extracted, the
dependencies are flattened in one step which avoids the extremely
inefficient recursive make that was previously used.
new and much more efficient code. Previously a 'make readme' took over
3 weeks on my SS5 and now takes < 3 hours. The number of make calls has
been reduced from somewhere over 1,000,000 to one per package which is
around 3,000. The mk/scripts/mkreadme script does all the work now. This
script has been used in standalone form for a month or two on ftp.netbsd.org
and has had no problem.
Otherwise a bad value of _PKGSRCDIR will be used and the bulk cache creation
fails. This didn't show up before because formerly _PKGSRCDIR was previously
set in bsd.pkg.mk instead of bsd.prefs.mk as it is now.
Should fix bulk build dependency problems noted recently by Hubert.
the cache files used during a bulk pkgsrc build.
- replace the code in the build script that used to create the cache
files with a 'make bulk-cache' call.
sets MKCRYPTO=no, packages in this category won't be fetched, installed,
built, or packaged. Also, binary package users forbidden, by law, from
using strong cryptography would presumably find the list on the category's
automatically generated web page useful for ensuring compliance.
