Is there a way to have src2pkg remember the configuration options for a package? Usually, I'd use comfigure to remember them, but when I do 'src2pkg -c=comfigure <file>', it hangs.

Should I just 'comfigure' and 'make' the package manually and use trackinstall to create the /var/log/packages/ entry (since I'm not too bothered about ending up with an actual .tgz file)?

No, just add -N to the options. That gives you a script with whatever options you choose:
src2pkg -N -e='--disable-whatever' tarball-name
Substitute --disable-whatever with any extra options to the configure script -excluding the --prefix option because it is separate. You don't have to worrry about --libdir, --mandir or --infodir either.

Then you can run the build with just:
src2pkg -X

You can also use whatever regular options and use the -A option instead of -N. The -A option will create the script when the build is finished instead.

Is there a way to specify a directory in which to place and to search for the scripts automatically, so I can keep them all in, say, ~/.src2pkg/?

Also, how to I prevent --prefix=/usr being used?

You can use p=/whatever, --pre_fix=/whatever or you can put PRE_FIX=/whatever in your src2pkg.conf file.

src2pkg always loks for the script in the current working directory, so you can put them anywhere you like. You can't put them in one place and run src2pkg from somewhere else, though. During the build src2pkg creates ome temp files in the CWD and looks for any extra files like patches, slack-desc etc in the CWD. You can put patches elsewhere, but it looks for most stuff relative to the CWD. Since internally extra files have generic names(slack-desc doinst.sh) it is best to have a separate directory for each package you want to build. That makes it easy to keep all the materials needed in the same directory. You can easily put sources elsewhere, though, if you want to keep them separate.

Explain to me a little more what you are wanting to do, and I'll try to suggest the best solution for you.

Thanks, gnashley. I noticed that PRE_FIX wasn't mentioned in the sample config file.

I download miscellaneous files to ~/downloads/. Some of these might be sources for things I've already installed. I'd like to be able to, from ~/downloads/, run src2pkg -X <one of these files.tar.bz2> and have it configure and make a Slackware package. If I've already configured a previous version of a package, then I'd like it to pick up on that and suggest the previous ./configure options for the new package - without keeping the .slack-desc and .src2pkg.auto files in ~/downloads/.

Hmmm, src2pkg doesn't have a way to update the version number of the sources for you. But, you can certainly store all your NAME.src2pkg(.auto) files in one directory and then specify which one to use:
src2pkg NAME.src2pkg.auto
The only trouble with that is that if any of your builds need a special doinst.sh file then you can only have one in the same directory, and if ti is found it will be used for any package you build from there. This is why I usually recommend that you keep the materials for each package separately. But if your builds are all simple it is no problem to keep everything together, but you'll have to edit the scripts when you update to a newer source version.

I just re-read your original post and want to clear up something. trackinstall is not exactly like the old checkinstall -it does not really install the software when it creates a package. In fact, this was the first thing I wanted to do differently with src2pkg, as opposed to using checkinstall. So, when you finish running trackinstall, the software is not really installed and you must install the resulting package using installpkg, or use the '-I' to src2pkg/trackinstall which will do it for you(if you are root).
These are valid commands:
src2pkg name-of-tarball
src2pkg name-of-script
You should not use -X with either name-of-tarball or name-of-script. The -X option causes src2pkg to *search* the current directory for a script to run and it will run the first one it finds.

Your idea of having it be able to use a newer source version with an old script is not a bad (or new) idea. And I might just implement such a feature -src2pkg does already have some similar 'update' features which cause it to update scripts or 'bump' the version num,ber without you having to hand-edit the script. We'll see what I think about it...