repack()
The function from hell
----------------------


The repack function was created as an easy way to make more than one
binary package from one source tree.  Programs such as egcs, XFree86, and
Emacs all have one source tree that generate multiple binary packages.

Repack was written so that the prototype author could call repack in the
special() function of the main prototype file.  Basically, it would just
take the package directory you specify, build the postinstallation file,
and tar it all up into a tgz package.  It was working like the existing
makepkg program, but internally.  You had to manually setup the package
directory before calling repack.  This got really difficult with things
like egcs and glibc.  Plus, if you needed to rebuild just one of the
packages, it didn't matter, you had to rebuild them all.

The new repack is a bit more friendly.  It works with a system of
prototype files.  Let's use egcs as an example.

The egcs source tree will create the egcs, egcsobjc, and egcs_g77
packages.  For this tree, we'll have three prototype files.  The master
and two subprototypes:

   prototype            (Master prototype, makes the main egcs package)
   prototype.egcsobjc   (Subprototype for the egcsobjc package)
   prototype.egcs_g77   (Subprototype for the egcs_g77 package)

You should understand how to write a prototype by now, so I won't go into
that.  I'll only explain the *NEW* function that's been added to the main
prototype file.  The subpacks() function.  This function should be listed
after your special() function.  It's used to call repack to make the
subpackages.  Here's what the subpacks function for the above prototype
file would look like:

   subpacks() {
      repack egcsobjc
      repack egcs_g77
   }

You only list the suffix of the subprototype file.  And don't specify the
full path, the package system will figure that out for you.

Now, the format of the subprototype files is a bit different.  First,
subprototypes inherit all of the existing settings...that includes all of
the settings from the main prototype.  So you can reference things like
BUILD, VERSION, and so on.  The subprototype file is usually small, since
the compilation has already been done by the master prototype file.
Here's the skeleton for my prototype.egcsobjc file:

   PKGNAME=egcsobjc-$VERSION-$ARCH-$BUILD
   DESC="\
   The egcs Objective-C compiler.  And what a thrill ride this is."

   subinstall() {
      ### here's where I install the contents of the egcsobjc package
      ### to the system...just like in install() in a master prototype
   }

   subattributes() {
      ### works like attributes() from a master prototype
   }

   subspecial() {
      ### if I need to do anything special to this subpackage, here's
      ### where I do it
   }

And that's it.  The repack function will use this file to put together
your subpackage.  The $PKG and $CTL variables have equivalent subprototype
verions:

   Master prototype variable            Subprototype variable
   $PKG                                 $SUBPKG
   $CTL                                 $SUBCTL

Be sure to use the correct variable reference, or else you will be
modifying the package tree for the master prototype file.  :)

The idea is that you compile the source tree once in the master prototype.
Then these subprototypes will pick and choose what to install for each
package, thus creating the individual binary packages from one source
tree.  If you must see a real live example, come ask me.

Let's say you fixed a bug in one of the subpackages and you need to
rebuild just that subpackage from source.  Naturally you don't want to
rebuild all of the packages from that source tree.  We can pass the name
of the subpackage we want to build to the protopkg command:

   protopkg -p <subpackage name>

Example:

   protopkg -p egcsobjc

The packaging system is smart enough to realize that it needs to run the
compile() function from the master prototype before it can proceed with
putting together the egcsobjc package, so don't worry about that.

If you want to rebuild just the package that gets generated from the
master prototype file, use the -p switch, but don't pass a package name.
Like this:

   protopkg -p

That will compile and build the package from the master prototype file and
skip building the subpackages.  The --package switch will also work in
place of the -p switch.

-David Cantrell
 <david@slackware.com>
