The easier stuuf first:

1. Look in the examples (in the docs/examples/GroupBuild) and study the group-build scripts there. They show a couple of ways to run src2pkg on the contents of a directory -you can set it up so it loops over all the tarballs or looks inside subdirs for tarballs or pre-made *.src2pkg scripts. The scripts are short and easy to understand and can be modified to do what you want. You can place them in the toplevel of your build area, or they could even be put into the path and then called from anywhere.

Also, you seem to have missed where this is mentioned: src2pkg now includes an example drag-n-drop application 'src2pkg-dnd' (it's also in the examples dir). There are notes in there that explain how to use it. But, Do you run KDE? If so, I'll have to work with you to get the dnd working usinf a src2pkg-dnd.desktop file. Since I don't use or even install KDE, I haven't worked out the details for using it that way, but I have an example *.desktop file which implements DnD for another program which should provide some clues.

---->> Let me know if you want to do that

You really don't need to modify src2pkg itself to add these extra routines -use the group-build examples for clues -you can have it do stuff after each (or all) packages are built, too.

2. src2pkg-N is handy, but I think most of what you want to do can be better done by using: 'src2pkg -VV -A -Q archive_name.
The '-A' option turns on the full automatic use of included *.sped or debian/rules files. src2pkg will parse out the configure options that are used there, corrects them (stuff like mandir and infodir) It also runs './configure --help' and saves the output into a file inside the sources. If the configure script is compatible with the '--help=short' option, it creates a second file -this one contains only the package-specific options available. If the options include the --sysconfdir or localstatedir options, these are automatically added to the configure options for src2pkg. These are the two most important ones which are pretty distro-specific and don't always match with --prefix, so they need to be set.

Using the -Q option makes src2pkg stop and ask you for options to the configure script.
But, read closely- Using them together dooes this: if there is a *.spec or 'control' file in the sources, then src2pkg parses out the configure options that are used there, corrects them (as above) and then shows you what it has found and corrected from the *spec or rules file, plus what it hass added(sysconfdir and/or localstatedir). But, it also opens a second xterm which cats the contents of the help file(the ouput from './configure --help' or './configure --help=short'). This shows you all the options available. You can select text from this xterm and paste into the main window where src2pkg is running. The pasted line is editable so you can take care of anything that src2pkg has gotten wrong(varying syntax in rpm files is not always 'translated' correctly.
I somehow think that --enable* will not work, but cut-n-paste is pretty fast and more dependable -a lot of --enables you will *not* alwys want -like debug, tests, profiling, others.

3. 'src2pkg --version' shows the version string. Use:
'src2pkg --version |cut -f2 -d'-''
to get just the number

4. Now the hard stuff :-(
Dependency resolution is extremely difficult to manage, and can only be done with some sort of database -either centralized or package/source based. What I mean is, tools like slackpkg or swaret use a huge list of all packages available and their dependencies. Debian uses 'control' files in both packages and 'debianized' sources which list the dependencies of each package or source. RPM-based systems do the same thing, at least for source(they may use a central database for tracking binary-package dependencies). ALL OF THESE require a lot of human input and maintenance so that the database info is up-to-date. There is clearly no way that one person could effectively maintain such a database. This is why I built the functionality into src2pkg which takes advantage of the 'human input' which is found in *.spec, 'rules' and 'control' files. This also why I recommend you to use rpm source archives or debianized sources whenever they are available.
The only other way that src2pkg could take advantage of pre-existing build info would be to look for it online -this is what I meant about using e-builds or other such files -look on the net for e-build, *.spec or other.
Dealing with the varied syntax of these files and with the syntax/commands to efectively search for and download these files amount to a huge nightmare.

The largest and most dependable database is debian, but the needed files are not found in open directories -you'd have to figure out what the name of the diff file might be and look for that, decompress, etc.

The next largest databse is gentoo, but the e-build scripts are completely useless to src2pkg -there is no way to parse out the wanted or needed options without having nearly all of portage installed or using similar (huge)code.

BSD 'ports' have the same drawbacks as e-builds.

cpan sources/packages contain their own depends info. src2pkg automatically packages cpan sources, but doesn't resolve the depends as of now. It will show you the text if any errors/missing modules are encountered.

Finding *.spec files is probably the easiest and could be managed fairly well with several possible repositories.

The easiest and most-compatible pre-made scripts 'ports' from crux, vector and other similar systems. But the list of programs covered is always gonna be small compared to deb/gento/rpm distros.

In conclusion, there is no way that you or I can create/maintain a database system which will always work(heck, even debian doesn't have *everything*). The GroupBuild scripts are designed for exactly this sort of thing -when a particular program has an 'unusual' set of dependencies, using a group-build for that group of packages makes it easy to use and update.

When you run src2pkg without '-VV' and a build fails, it will pop up an xterm showing you the lines from the control or spec file which indicate the dependencies of the package.

If you want to create packages which contain dependency info, then uncomment one or both of these lines in your srcpkg.conf file:
ADD_DEPENDS_IN_DESC="YES"
ADD_REQUIRED_FILE="YES"

Tips about creating modifications to src2pkg -anything that deals with more than 'one package' should be done with a controlling script(like the GroupBuilds). Possible modifications to internal functionality is usually best done by inserting the code into a *.src2pkg script at the place where the extra steps should be done.
this makes it much easier to debug and move around -once running correctly the whole block of code can be written into a function and inserted with the other funtions. Then only one line is needed inside the src2pkg wrapper or inside of an already-existing function in oredr to call the new function.

Hi Gilbert,
It seems I'm destined to bad luck. I just rebuilt an old to an essentially new machine. New 2gb of memory and 500gb harddrive. After less than one week (and with 26gbs of new data), the drive died (Wednesday). So I didn't get this one up until yesterday. I really need to start using RAID1 for all my / partitions from now on. Just more money!

Just now seeing the amount of time that you spent in answering me. Always very much appreciated. I will take the time to read through your answer now and edit this further later on.

Shingoshi

Gnashley, yes I'm one of 'those' people who absolutely despise Gnome. I have(had) it installed, mostly for the applications it provides. But I really don't like the interface. So yeah, I use KDE. I'll be more than happy to help with the integration of your application into KDE.

I'm likely being very unfair about Gnome, since it's been such a long time since I've used it. When I rebuild this machine again with a new drive, I will reinstall Gnome and test it. Then I can be more fair in my estimation of the new interface, since it's been a very long time since I used it. I just like how everything I want is always integrated into the KDE system. Others call that *bloat*. I call it functionality. And yes, I'll admit it, I like the eyecandy!

Gnashley,
Sorry I haven't reported back until now. I finally got a 1TB drive to replace the 500GB drive which failed. And upon installing that system on the new drive, I forced it to construct a degraded RAID1 for my root. Seems the system doesn't like to boot in degraded mode (with lilo or grub). Which begs the question, 'what's the point of having RAID1 on the root, if the system won't BOOT! Granted, you may have a safe and secure system when you add the second drive, but you'll have to boot from a CD/VD or USB drive to run your system. Just a nuisance. Anyway, I built yet another system from components that a friend brought over to me.

1. I just tried compiling two programs which produced errors. The first was povray (http://www.povray.org/redirect/www.p...ay-3.6.tar.bz2), which requires the builder's name and email address on the ./configure line in this form. COMPILED_BY="$BUILDER'S_NAME BUILDER'S_EMAIL_ADDRESS". Putting this on the EXTRA_CONFIGS line in the povray.src2pkg file, doesn't work. At least, I haven't gotten it to.

2. I also tried to compile nvclock (http://www.linuxhardware.org/nvclock...k0.8b3a.tar.gz). It compiles and packages just fine, except that there is a recursive /tmp directory in the package which finally ends with /usr/bin. We've dealt with this before, but I don't remember what was done to fix it. Anyway, I simply copied the correct directories in the package into another folder with the same name, and manually ran makepkg to create the corrected package.

Just for a heads up. I'm not yet fully up to par on my systems. It may be a while. I have to order the second 1TB drive to fix the RAID1 issue I'm currently dealing with. After that, I will then attempt to slowly recover from all the other woes I've been dealing with. That will also include bringing my email back online, as I currently don't want to have it running on a system I don't trust.

Hope all is well,
Shingoshi