Subject: How to speed up extracting PKGNAME
To: None <>
From: None <>
List: tech-pkg
Date: 06/19/2004 04:04:48
 	There are currently two ways to extract PKGNAME from a package
 	- Use 'make show-var VARNAME=PKGNAME' or equivalent
 	- Parse the Makefile by hand

 	The first is slow, particularly if you want to parse many makefiles
 	(for example pkg_chk); and the second, while faster, is still quite
 	slow and error prone (see the glorious mess that is lintpkgsrc).

 	Either way, we do not have a fast reliable way to extract PKGNAME.
 	For a single file its fine, but for a large number of packages...
 	it hurts, and pksgrc is not getting any smaller.

 	Does anyone have any ideas on how to speed things up?

 	Thought 1)

 	    PKGNAME is currently derived from DISTNAME by default. If this
 	    was the other way around then the majority of Makefiles could
 	    start PKGNAME=<some_fixed_string>. This would allow scripts the
 	    option to try to 'quick extract' the PKGNAME, and then fall back
 	    to 'make show-var VARNAME=PKGNAME'.

 	    Of the ~5500 package Makefiles on a box here ~4700 start with

 	    It would involve a transition phase whereby DISTNAME
 	    could be derived from PKGNAME and PKGNAME from DISTNAME
 	    depending on which was defined.

 	    I see three issues

 	    - PKGREVISION. This could be handled by just adding
 	      nbX to the end of PKGNAME, which would be automatically
 	      stripped off for DISTNAME. The sub issue there is
 	      what to do if someone releases a program ending 'nb8'
 	      or similar

 	    - Makefiles which do strange dances setting PKGNAME
 	      and DISTNAME based on any number of arbitrary
 	      other variables - these would be pretty much left alone.

 	    - The amount of effort involved in changing over.

 	Thought 2)

 	    Make it easier to generate per OS+ARCH cache file of
 	    all packages and versions available for that OS+ARCH
 	    combination, ideally something in the form PKGDIR
 	    PKGNAME-VERSION, and possibly also with DEPENDS
 	    afterwards. We probably have something that can do
 	    this... though I'm buggered if I can find it right

 			   David Brownlee --