This directory contains code 'extensions' which can be used with
src2pkg to add extra functionality. In order to use extensions with
src2pkg, you must place the extension files in a special directory
under your HOME directory. You must create this directory as it
will not be done for you by src2pkg.

You can create the directory like this:
cd $HOME
mkdir -p .src2pkg/extensions

Then copy whatever extension files you want to use inside the new
directory.
You must also enable the use of extensions in the /etc/src2pkg/src2pkg.conf
file, by uncommenting the line:
# ALLOW_USER_EXTENSIONS="YES"
so it looks like this:
ALLOW_USER_EXTENSIONS="YES"

Creating and using extensions:
src2pkg normally runs 16 'functions' or named instructions during
each build. The following list shows the names of the fuctions,
as seen in any *.src2pkg build script, preceeded by the number
of that function:

1  pre_process
2  find_source
3  make_dirs
4  unpack_source
5  fix_source_perms
6  configure_source
7  compile_source
8  fake_install
9  fix_pkg_perms
10 strip_bins
11 create_docs
12 compress_man_pages
13 make_description
14 make_doinst
15 make_package
16 post_process

src2pkg extensions can be created and used to add extra code to
src2pkg at each step in the build process. Extensions can be run
either before or after the normal code for each build instruction.
Code which should be run *before* the normal build instruction should
placed in a file with the number of the build instruction plus '.post'
as the file name. For instance, say you want to run some extra code
after function number 13 (make_description) runs. Simply place the
code in a file name 13.post and put the file in your ~/.src2pkg/extensions
directory.
Just such an extension is included here in the directory named 'vector'.
As you might guess, the extension is for use when using src2pkg on
a vector linux system. The 13.post extension adds extra lines to the
slack-desc file which are wanted on vector linux systems.

The 'user extensions' feature is provided as a convenience for anyone
who wants to hack the src2pkg code or is unhappy with the way it does
(or doesn't do) certain things. For system sanity and safety, the feature
is disabled by default. I can't be responsible for whatever happens
to your system by using extensions, but here are a few tips which
will help you create sane code for use in extensions.

1. Any code extensions will always be run, as long as the extension
file is present in $HOME/.src2pkg/extensions, so do not place code
in an extension which is supposed to work only for certain packages.
Code which should apply to specific sources or packages should always
be placed in an individual *.src2pkg build script for that package.
This includes commenting out certain steps so they are not performed
or placing extra code between the normal steps.

2. Any code which is used in an extension becomes the first or last code
run by the named instruction. That is, if you put code in an extension
named '4.pre', then that code will be run before any of the normal code
in the (#4) unpack_source function. And placing code in an extension
named '14.post' means that the code will be run after all other code
from the (#14) make_doinst function is run. This means that you can
always have the first and/or last word as to what a function does.

3. You are responsible for any error checking or prompts which are used
by your code. It is best to start out by writing the code so that no
real actions are performed. Instead you'd insert lines which output
a prompt (using echo) which would show what the intended code would do.
Then, once you have verified that the code is really being run at the
place you want, you can substitute the echo staements with the real code,
or even better, add the real coe and leave the echo statements there. This
way you'll always have visual evidence that the code is being run. It can
also be helpful to temporarily insert and 'exit' statement just after
the exetension code ir run(either in the extension code itself or in
the *.src2pkg script. This will allow you to halt the execution of
the build just after your code is extension is run and allows you to
verify that the code is doing what you want.

4. While I can't be responsible for what your extension code does, I am
willing to help you decide whether an extension is the right thing to use
and where you might execute the code in order to achieve a certain result.
You can always email me at <amigo@ibiblio.org> with any questions or
suggestions. extensions provide an easy way for you to change or extend
the functionality of src2pkg, so if you come up with an extension which
you think might be useful to others, send it to me. After reviewing and
testing it, I may include it in the examples provided here. If it provides
functionality which would benefit src2pkg in gerneral, then the code might
be worked into the regular src2pkg code base.