CVS log for pkgsrc/benchmarks/dbench/Makefile

Up to [cvs.NetBSD.org] / pkgsrc / benchmarks / dbench

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

use https

Use OPSYSVARS.

(upstream) update 3.04 to 4.0, changes unknown.
(pkgsrc)
 - Add comment on patches picked from cvs log
 - Add ${LDFLAGS} on patch-ab for Makefile.in

Remove pkgviews: don't set PKG_INSTALLATION_TYPES in Makefiles.

"user-destdir" is default these days

Remove chunk that was added for 1.6.2 compatibility, but affects the
run-time. Noted by yamt@ in PR 45866.
Bump PKGREVISION.

user-destdir support

Update dbench to 3.04.
Changes is unknown.

While here,
 * install README file mentioned in man page, suggested in PR 38553.
 * move client.txt to subdir noted in man page
 * fix directory of those files in man page.

Point MAINTAINER to pkgsrc-users@NetBSD.org in the case where no
developer is officially maintaining the package.

The rationale for changing this from "tech-pkg" to "pkgsrc-users" is
that it implies that any user can try to maintain the package (by
submitting patches to the mailing list).  Since the folks most likely
to care about the package are the folks that want to use it or are
already using it, this would leverage the energy of users who aren't
developers.

Explicitly specify to Makefile.in the directory on which the manpages
will be installed, otherwise as --mandir now defaults to
${PREFIX}/${PKGMANDIR}, they won't be installed into the correct location.

Bump PKGREVISION.

Added a chunk to patch-aa that comments out unnecessary code (statvfs). Now
the package builds on NetBSD-1.6.2. Bumped PKGREVISION.

Changes 3.03:
* Many improvements

Changes 2.1:
* unknown

Update MASTER_SITES.

Enable pkgviews installation.

Move WRKSRC definition away from the first paragraph in a Makefile.

Make compile on Solaris. From Jonathan Perkin in PR 22858.

s/netbsd.org/NetBSD.org/

Initial import of dbench-1.3 into the NetBSD Packages Collection.

Taken from the dbench README file:

	Netbench is a terrible benchmark, but it's an "industry
	standard" and it's what is used in the press to rate windows
	fileservers like Samba and WindowsNT.

	In order for the development methodologies of the open source
	community to work we need to be able to run this benchmark in
	an environment that a bunch of us have access to.  We need the
	source to the benchmark so we can see what it does.  We need
	to be able to split it into pieces to look for individual
	bottlenecks.  In short, we need to open up netbench to the
	masses.

	To do this I have written three tools, dbench, tbench and
	smbtorture.  All three read a load description file called
	client.txt that was derived from a network sniffer dump of a
	real netbench run.  client.txt is about 4MB and describes the
	90 thousand operations that a netbench client does in a
	typical netbench run.  They parse client.txt and use it to
	produce the same load without having to buy a huge lab.  They
	can simulate any number of simultaneous clients.

Initial revision