When you run package/install, the following scripts are run:
package/compile builds the package. It is made of three phases:
package/prepare takes all necessary steps to prepare the compilation. It creates the compile/ subdirectory in which the build will take place, it imports the files from the directories listed in conf-compile/import, and so on. If conf-compile/import does not contain the proper dependencies, the build may fail here.
package/make is the real build process. Every subsystem listed in the package/subsystems file is built one after the other; the order is important. If your build fails, it will most likely fail here.
package/makeinstall "installs" the software locally: the needed binaries, libraries, header files, ... are copied from the compile/export/ directory, where package/make puts them, to the command/, library/, include/, ... directories - where they are made available in /package-fashion.
package/upgrade is a bad name, but it's there for historical reasons. It performs the following:
The skarnet.org packages all follow the /package convention, which, among other things, means that:
Nevertheless, some misguided people do not understand the benefit of /command. For them, package/compat also exports registered commands in /usr/local/bin. The bazqux command will then be available as /usr/local/bin/bazqux.
If your system is /package-compliant, then you don't need to run package/compat at all.
If additional action must be performed on your system for the package to work properly, package/run performs it. For instance, if the package provides a service, package/run could start that service. Or it could restart another service on your system, if proper operation of the package depends on it. Most of the time though, package/run does nothing: it is up to the system administrator to set up the services as he sees fit, and to know exactly what steps should be taken on his system for everything to work as expected.