>Number:         35567
>Category:       pkg
>Synopsis:       pkgsrc (binary packagre) extra info request
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 08 09:45:00 +0000 2007
>Originator:     Robert Elz
>Release:        NetBSD 3.99.15 (All versions & all versions of pkgsrc)
>Organization:
	Prince of Songkla University
>Environment:
System: NetBSD jade.coe.psu.ac.th 3.99.15 NetBSD 3.99.15 (GENERIC-1.696-20060125) #8: Wed Jan 25 04:59:39 ICT 2006 kre@jade.coe.psu.ac.th:/usr/obj/current/kernels/JADE_ASUS i386
Architecture: i386
Machine: i386
>Description:
	I have filed this as a pkg category change request
	(the ;ackage would be pkgtools/pkg_install I believe)
	but it cuold also be a bin category against usr.sbin/pkg_install
	I've never been sure which of those is the master, and which
	the copy...

	I'd very much like to see bnary packages add one extra info
	field (variable, whatever you want to call it, or however it
	should be implemented) to indicate the source pkgsrc directory
	(eg: graphics/png) from which the binary package was constructed.

	For most packages this won't add much useful, as the source
	directory (the pkgsrc source directory) is trivial to guess,
	and the obvious guess is correct 99% of the time.

	With a few packages, guessing is just plain annoying, with
	others, it is close to impossible (and things get much worse
	when a package is removed, and the source directory no longer
	exists).

	Recording the source directory would make tracking what
	happened to a binary package (and just finding the place in which
	it can be reconstructed) much easier, at almost no cost.
	Even in the case of removed (or moved) packages (in all cases
	but repository move, which is thankfully rare) this enables
	tracking what happened, as the CVS Attic remains to give a
	log of what happened, and why.

>How-To-Repeat:
	Just wonder from where a binary package originates, then
	see if you can find a way (other than enumerating the names
	of every existing package and comparing - using an intelligent
	compare, as version numbers can differ, and the py-* and ruby-*
	binary package naming makes things interesting)

	I have been wanting this for ages - I currently use a (very ugly)
	heuristic script to guess for me, but it keeps failing...

	Most recently, I found I needed this when lintpkgsrc (-p) told
	me that my binary package py24-gtk-0.6.11nb3.tgz was no longer
	current.   What I typically do in that case, is find the
	pkgsrc directory, and rebuild.  The rebuild is easy, the "find"
	not so easy (even when one knows that pyNN-* packages are found in
	py-* pkgsrc directories).   I last compiled py24-gtk-0.6.11nb3.tgz
	last August.   I have no idea from which pkgsrc directory.
	x11/py-gtk seems to have been rmeoved in 2001 (approx) and
	replaced by gnome-python (though whether that one made py-gtk
	packages or gnome-pytrhon packages I have no idea).   The
	latter seems to have been removed in 2005 sometime (if I read the cvs
	log correctly).   What, if anything, existed in Aug 2006 to
	build this package I have no idea...   I certainly cannot find
	it.   If the binary package would just tell me its origins,
	all would be easy...

>Fix:
	Add a little code to the code that builds binary packages,
	and to pkg_info to report the value...

	I know (believe, or perhaps hope) that pkgsrc is currently
	being revised for other reasons, so I won't attempt to hack
	this into the current sources and send a patch - consider this
	a feature request for the next version.