Lufbery, your experience with trying to package Open Office shows that not everything can be done automatically. This is especially true for large, complicated packages that support mulitple platforms. It would be impossible to write a program which would figure out all the options and possibilities and do the right thing without human intervention. This shows how important it is to take the time to examine what is happening when your packages are built and how they work once installed. src2pkg mostly tries to take the tedium out of running the same old steps time after time while you figure out what is needed to make the package really work. Of course, in may cases, no adjustments or extra code is needed. You were perfectly right to consult with a SlackBuild script, or even with an rpm .spec file if one is included. Usually you can just cut and paste the few needed lines from a SlackBuild script.
In the case of the above mentioned fixes for Open Office, only the relocation of the docs would be handled automatically by src2pkg. The other fixes can be done either by adding the lines of code to the src2pkg script or from a doinst.sh script. Any code you add in the script which creates links will be automatically written to a doinst.sh -unless you have supplied one. Some stuff can only be done from a doinst.sh, anyway. src2pkg makes it possible for you to combine manually written code for a doinst.sh with automatic creation of the link-creation code.
For manual adjustment of paths in the package you should usually add the code after the fake_install function is run, using the $PKG_DIR variable (although as mentioned you can paste code from a SlackBuild which uses $PKG).
I see that it mentions wrappers -these will have been manually adjusted or edited using a patch or sed within the SlackBuild. For wrappers, I usually create or alter them manually and then just add the code which places them in the package.
For instance, Open Office is started with a link in /usr/OpenOffice.orgx.x.x. which points to a wrapper which calls a binary. This is kind of a worst case scenario for such things. What I did for OpenOffice is create a wrapper to place in /usr/bin with this content:

#!/bin/bash
# soffice.wrapper
cd /usr/OpenOffice.org1.0.3 && exec ./soffice "$@"
exit 0

So, we have a wrapper which calls a link which is linked to *another* wrapper. A real mess this one, but the thing is that you need to be inside the main /usr/OpenOffice directory when you call the binary so that it can find its' other directories which contain all the binaries and shared data.

So then, the wrapper is placed in the same directory as the sources and src2pkg script and gety inserted into /usr/bin like this:

mkdir -p $PKG_DIR/usr/bin
cp $CWD/soffice.wrapper $PKG_DIR/usr/bin/soffice
chown root:root $PKG_DIR/usr/bin/soffice
chmod 755 $PKG_DIR/usr/bin/soffice

Moving pixmaps or other files is done in a similar manner -The only variables you need to understand are $CWD, $SRC_DIR and $PKG_DIR. Otherwise the commands are usually just like what you would do from the command-line.

Most software can be packaged well with little or no fixes of this sort. But some programs need lots of lines of manually inserted code which must be worked out and proofed by rebuilding many times. Still src2pkg makes it as easy as possible to do so without requiring you to be an expert script writer. If you have a look at the script I mentioned above for gcc-3.4.6, you'll see that it is mostly taken from the regular SlackBuild script and contains probably 50 lines of 'manual' code. Certainly a worst case scenario, but still no reason to not take advantage of whatever src2pkg can do automatically. In difficult cases, you simply comment out the src2pkg function and insert the manual code that is needed -usually this is either the code for configuration, compiling or installation of the software. Each src2pkg function can pretty much stand alone, so you can skip or add to any of the functions without losing the functionality of the rest. And even if it takes 50 lines of manual code, if it saves you writing and testing another 25-50 lines then it has made things easier.

I see that you tried out some of the other uses of src2pkg for creating packages from pre-built binaries like Opera, and for converting binary rpm's. It can also be used as a structure for creating 'noarch' packages or basically any kind of content at all.

I appreciate you taking the time to and choosing to review src2pkg for Linux.com. It will give some exposure for Slackware, as well.
I appreciate also the constructive-spirited criticism. I've never been happy with the documentation and have started over several times. I always wind up getting bogged down. I don't have to tell you how difficult it is to write clear concise paragraphs -especially for technical writing. The documents are spread out as a way of trying to resolve the main problem of writing good tech info -that is to be able to focus the writing toward a certain user knowledge level. Many users don't care to know about the why's or how's of advanced features. But others are keen to know exactly what src2pkg does and, why it does it that way, at every step. Since src2pkg (and trackinstall) have lots of capabilities it makes for a lot of info which should be provided. Now that the functionality and features have mostly stabilized there is a better chance of getting it right. As I mentioned to you privately, I used to write professionally, so I'm quite aware of the shortcomings. But I'm a typical coder in that I'd rather write code than document it. And by now, my level of experience makes it somewhat difficult for me to write effectively for less experienced users.
Anyway, thanks again for *your* efforts.

Gilbert,

My review is slated, tentatively, to be published on Linux.com on Thanksgiving day, November 22nd.

The approach you outlined above for Open Office is what I started to figure out would be appropriate. But, I only started to figure that out after building a handful of packages a few different ways.

In any event, I'm saving this thread because your instructions are so clear and helpful.

As for the documentation issue -- I understand the challenge of writing technical documentation. What level of experience do your users have? What are the common problems they'll encounter? What information is most critical for them to know? What information will enhance their understanding after they've been using the product for a while? Etc.

It's a tall order.

Warm regards,

-Drew

src2pkg-1.7 has been released, so I'll refer those reading this thread to the new thread which announces the new release. Please see here:
http://www.linuxquestions.org/questi...5/#post2962328