

1. Notes on the use of INSTALL_TYPE

2. Passing options to the 'configure' script

3. Building packages as a normal (non-root) user

4. Controlling execution using the --pause or --resume options

5. Building packages for multi-lib systems

1. Notes on the use of INSTALL_TYPE
	One very important variable used by src2pkg is called INSTALL_TYPE. This
	refers to the way in which package content gets created using the
	'fake_install' instruction or function. fake_install is a 'front-end'
	to whatever command is normally used to install software to your system
	-usually the command 'make install'. fake_install provides 5 distinct
	methods to run the installation commands -usually without installing
	the items at all. fake_install tries to run the commands while re-directing
	them so that software gets installed into an alternate location -the PKG_DIR.
	Two of the INSTALL_TYPES are available to non-root users: '-DESTDIR' (or '-DEST')
	and '-JAIL'. Three more types can only be used while running src2pkg as
	root: '-REAL', '-SAFE' and '-UNION'. The UNION option sets up a small
	chroot environment using fuse and unionfs. Software is installed into
	the chroot environment so it can be isolated from the real system
	directories. As implied, the REAL option actually installs the software
	to your system, but creates a log of all files created or modified, then
	copies them into the PKG_DIR and finally removes them from the main
	filesystem. However, this can overwrite files which are already on your
	system. Using the SAFE option avoids changes to your system, by creating
	backups of any files which would be overwritten, and then restoring them
	once the new files are cpoied into the PKG_DIR.
	
	The REAL and SAFE methods are the most accurate and dependable methods,
	but unfortunately they are the most intrusive as they don't even try
	to re-direct the output of the installation commands. For that reason,
	we recommend only them only when none of the other methods work.
	
	By default, src2pkg will use the JAIL method for content creation. For
	a long time, the DESTDIR method was the default as many people are familiar
	with it and truyt it. However, DESTDIR is not dependable and will often
	write some files correctly to the DESTDIR(PGK_DIR), but will try to write
	other files to the main system directories. This means that, if running
	as root, you will have 'orphaned' files on your system which are not
	included in the package, or if running as a normal user, then the commands
	will fail. Failing is better than creating orphan files, but since the
	failure stops the src2pkg build process, the user is left without a 
	package. Usually, the JAIL method will succeed in these cases. The JAIL
	method will also fail sometimes, for reasons which are difficult to
	discover or explain. But it makes a safer default than DESTDIR and will
	not fail more often than DESTDIR.

2. Passing options to the configure script
	For compiling many sources, you'll want or need to pass extra options
	to the configure script to enable or disable program features. Of course,
	src2pkg provides a way to easily do this, either using command-line
	options or by including the extra options in a src2pkg script. Let's
	take an example where you want to build and package a certain program,
	but need to pass some extra options like: --disable-gnome --with-x
	When normally configuring such sources you'd use a command like this:
	./configure --prefix=/usr --disable-gnome --with-x
	When using src2pkg, the prefix option is separate and defaults to /usr,
	so normally you shouldn't have to worry about it. The command-line
	for doing the above using src2pkg would look like this:
	src2pkg -e='--disable-gnome --with-x' tarball-name
	If you really wanted to use a prefix besides /usr, supply it separately:
	src2pkg -p='/usr/local' -e='--disable-gnome --with-x' tarball-name
	You can also use the "long form" of the src2pkg syntax, like this:
	src2pkg --pre_fix='/usr/local' --extra_configs='--disable-gnome --with-x' tarball-name
	
	If you are using a src2pkg script to build the sources with, you should
	use the same syntax that src2pkg uses for its' internal API:
	PRE_FIX=/usr/local
	EXTRA_CONFIGS="--disable-gnome --with-x"
	(Be sure to use quotes if the options contain spaces).
	
	You don't have to learn all the internal syntax in order to be able to use
	a src2pkg script, as src2pkg will write the script for you with the correct
	syntax for any options you give on the command-line. This command:
	src2pkg -p='/usr/local' -e='--disable-gnome --with-x' -N tarball-name
	The '-N' option tells src2pkg to create a new src2pkg script for you,
	and the extra options you passed will be written into the script with
	the correct internal syntax as shown above.
	
	The '-e=??' (or EXTRA_CONFIGS) option can also be used to pass options
	to other configuration methods, including those used for compailing
	perl-modules or sources which use 'cmake' for configuration.
	
3. Building packages as a normal (non-root) user		               ####
	Most software can be built with src2pkg while running as a non-root,
	non-privileged user. In these cases, src2pkg uses the owner/group commands
	of 'tar' to set the ownership and group of all files to 'root', so
	the package can be installed normally to your system. However, there
	are cases where this is not the desired result. For instance, some software
	installs files or directroies which belong to a specific non-root user,
	particularly server or daemon software which may run at boot-time. In
	these cases you have two options: build the package as root so that
	the correct onership and permissions are preserved, or include lines
	in a doinst.sh script which set the owner/group/perms when the package
	gets installed.
	
	Also, there are a few cases where neither the JAIL or DESTDIR options
	(descibed above) will work to create the package content. In such cases,
	the package must be built as root, using one of the other INSTALL_TYPE
	options.
	
	rpm packages should usually not be built as a non-root user as rpmbuild
	will set the 'owner' and 'group' of all files to the normal user.


4. Controlling execution using the --pause or --resume options		####
	You can control the flow of execution of src2pkg using the options
	'--resume=??' and/or '--pause=??'. These options are not meant to
	be used so that you can do things manually inside the sources or
	in the package-tree content. When resuming, src2pkg will automatically
	clear out any previously-created content in the package tree.
	
	The 'resume' is especially useful when working with sources which
	take a long time to compile. You may want interrupt a build which
	is taking more time than you have. It is also useful if you are
	creating more than one type of finished package. To use the resume
	option, simply give the name of the src2pkg function or build
	instruction where you want src2pkg to resume at -for example:
	src2pkg --resume=compile_source
	will resume the build at the compile_source function. You can see
	a list of the functions where builds can be resumed, by running 
	'src2pkg --list'
	
	Usage of the 'pause' option is similar. By using 'pause', you can
	have src2pkg pause before or after each step of the build. Or you
	can have it pause at just one build step. To pause before or after
	every step, use the pause option like this:
	src2pkg --pause=after (or --pause=before)
	Or, to have src2pkg pause at a single step, use the name of the
	function or build instruction, as above:
	src2pkg --pause=fake_install
	As above, the command 'src2pkg list' will show you the list of
	functions available for pausing. When used this way, the 'pause'
	option will both before and after the named function.

5. Building packages for multi-lib systems
	src2pkg makes it very easy to build packages for multi-lib systems.
	The most common case for this is with 64-bit systems which also
	have some 32-bit libraries and programs installed. src2pkg provides
	command-line options for easily controlling multi-lib builds. The
	two main ones are the '-M??' and '-L??' options. The -M?? option
	is used to tell src2pkg which 'Machine Option' to pas to the compiler,
	and the -L?? option is used, when needed, to tell src2pkg the
	path-names to use for configuration and installation of the package.
	The most common case would be something like this: You have a 64-bit
	system with some 32-bit compatibility libraries already installed.
	For most systems, the 64-bit libraries are installed under /lib64
	and /usr/lib64, and the 32-bit libraries are installed under /lib
	and /usr/lib.
	To compile and package a program which uses the 32-bit libraries,
	simply add the option '-M32' to whatever src2pkg options you are
	using. If you are using a system which uses a different directory
	structure, you can use the -L?? option to control the path-name
	to use. The most common options are avilable as simple 'switches':
	-M32, -M64, -L32, -L64 (and -L0 or -LNULL). But there is also a
	long-form syntax which can be used for creating packages using
	a cross-compiler. Instead of the -M?? option as shown above,
	you can use: --machine=??; and for the -L?? option: --libdirsuffix=??
	Using the long-form syntax lets you specify any sort of directory
	name and/or gcc 'Machine Option' needed.
	
	