A spell follows the following path during its installation: PREPARE -> DETAILS -> PRE_BUILD -> BUILD, or COMPILE/INSTALL -> POST_BUILD -> POST_INSTALL -> TRIGGERS Each of these steps, along with some interim steps of dealing with conflicts and security are handled here as well.
Copyright (C) 2002 The Source Mage Team <http://www.sourcemage.org>
$SGL_LIBRARY_MODULES $GRIMOIRE $BUILD_API $USE_FUNCTIONS
Functions for dealing with the actual compiling/installation of spells and walking through cast's 'pass 4' pipeline.
This is used to dynamically setup an api environment for a spell into the build api that it is specified to use. (ie split BUILD or no split BUILD).
Load the grimoire and section level FUNCTIONS file
Load the grimoire and section level 'libcompat' file Spells use this for compatibility checking. It is supposed to be lighter-weight than FUNCTIONS.
$SPELL_CONFIG $DEPENDS_CONFIG
Loads up this environment with the special configuration values that the spell needs. Typically the mode of communication between CONFIGURE/DEPENDS to PRE_BUILD, BUILD, COMPILE, INSTALL, etc.
Prompts the user about spells that are in conflict with the current spell for later dispelling. If the user chooses not to dispel the conflicting spell, the function returns 1
Dispels the spells that are scheduled for a dispel due to conflicting
Prompts the user about possible security problems with the current spell. Allows a safe way of failing a spell due to security problems.
Asks the user about init and xinetd services expects $SCRIPT_DIRECTORY to be setable, any file one level deep in $SCRIPT_DIRECTORY/xinetd.d or $SCRIPT_DIRECTORY/init.d is assumed to be a service the following persistent variables may be set: XINETD_ENABLED XINETD_DISABLED INIT_ENABLED INIT_DISABLED XINETD_INSTALLED XINETD_NOT_INSTALLED INIT_INSTALLED INIT_NOT_INSTALLED They are all lists used by the list_add/list_find functions. The union of FOO_ENABLED and FOO_DISABLED should be exactly equivalent to FOO_INSTALLED. FOO_ENABLED and FOO_DISABLED have an empty intersection set.
a menu sans question, the caller needs to present the question
Determines what the best default answer should be then gives the user a menu of neither, init, xinetd, or both to choose from. This is for the case of a service being provided by either init or xinetd
a query supplied by the caller
Determines what the best default answer should be then asks the user given question and adds the service to one of two lists
Internal wrapper around the task of adding a persistent variable then storing something in it, or unsetting whatever used to be in it
Installs the scripts selected from query_services
Does the dirty work involved in installing an xinetd script this includes setting the disabled field appropriately and not trampling on pre-existing files by default
Handles the logic of enabling or disabling of an xinetd script
Copies any init.d files from the SCRIPT_DIRECTORY to the /etc/init.d. Hopefully saving the old one if it exists and only setting the executable bit if the user specified that the init.d script should be started at bootup.
Gets the cast lock for us and ensures that we've waited for all solo/non-solo casts to complete
Takes the compile log and stuffs it into our compile log directory.
Prompts the user to view the compile log and deletes the temporary files too
INST_LOG
Report that something got installed, and possibly display the report Pawns the work off to var.lib.sorcery.modules.libsorcery
This function is dumb. It should be fixed.
fix the old style ad-hoc IPC
Shows download progress. Waits for the download to start, and shows the progress until the download is done. Pawn most of the display out to show_download_progress
file name
Gets the filename of the download log file