Class archive software packages6401241Abstract SYSTEM V utilities enable software developers to provide delivery of complex packages onto a UNIX operating system. An enhancement to the UNIX System V ABI format called class archive format enables sets of files to be combined into archives, these files being compressed or encrypted. The compressed/encrypted ABI package install with behavior defined in System V ABI. The class archive format allows a manufacturer to combine files from the ABI format reloc directory and root directory, into an archive directory. Class action format adds a directory called archive to the ABI format. Any class of files that are intended for archive is combined into a single file, and each file is then placed into the archive directory as class1, class2, etc. All files that are archived in this manner are removed from the standard ABI reloc directory and root directory, and an install class action script is placed into the scripts portion of the standard ABI install directory. Three interfaces are provided in the form of three keywords. These three keywords are (1) PKG_SRC_NOVERIFY, (2) PKG_DST_QKVERIFY, and (3) PKG_CAS_PASSRELATIVE. These keywords are used to designate classes of the archive directory that require special treatment. The format of each keyword statement is "keyword=class1 [class2 class 3 etc.]". Each class action script contains Bourne shell commands that are executed by pkgadd to install the files from the archive directory. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
#Class action script to extract the cpio
archive of
#class1. The archive is in archive directory
17, and
#it is named class1.
BD=$ {BASEDIR:-/}
FILELIST = /tmp/extractlist$$
read path
if [ $ {path: -NULL } !=NULL ]
then
PKGSRC=$path #this is where the source
pkg is
else
exit 0 #empty pipe, we're done
fi
#now we know where the archive is
Reloc_Arch=$PKGSRC/archive/class1
#create extraction list
while read path
do
echo $path >> FILELIST
done
#Now extract the files from archive directory
cd $BD
#Go to the correct base directory
cpio -idukm -I $Reloc_Arch -E $FILELIST
rm $FILELIST
exit 0
Of these three keywords, only the keyword PKG_SRC_NOVERIFY is an absolute requirement for implementing a class archive package in accordance with the present embodiment. However, use of the other two keywords is desirable in order to increase installation speed and/or to conserve code. In a preferred embodiment, for each archived class of archive directory 17, a class action script 18 is required in scripts 16 of install directory 15. Each such class action script 18 is a file that preferably contains Bourne shell commands, and each such class action script 18 is executed by pkgadd to install the files from archive directory 17. If a class action script 18 is found in the install directory 15 of the package 10 being installed on a target system, pkgadd operates to turn over all responsibility for installation of that class to that class action script 18. The class action script 18 is then run with root permissions, and the class action script 18 can then install its files onto the target system. Again with reference to FIG. 2, a multi-step example of the utility of the present embodiment will now be provided. Step (1)--The manufacturer of software package 10 decides what classes are to be archived in archive directory 17, and what special method of archive is to be used; for example, compression and/or encryption. Step (2)--For each such special class, a class action script 18 is written that will operate, when executed by pkgadd, to extract that class from archive directory 17. Step (3)--The necessary keywords are added to pkginfo file 11. For example, if class1 and class2 are to be archived and the installation of class1 is adequately confirmed in class action script 18, the entries to pkginfo 11 would be as follows: PKG_SRC_NOVERIFY=class1 class2 PKG_DST_QKVERIFY=class1 Step (4)--All class action scripts 18 are then included in the prototype file to the System V pkgmk Utility. Step (5)--Package 10 is created using this pkgmk utility. This results in package 10 being constructed with class1 and class2 files in reloc directory, 13 or root directory 14. Step (6)--Archive directory 17 is then created in package 10. Step (7)--Class1 and class2 are archived in archive directory 17. Step (8)--Class1 and class2 are then deleted from relic directory 13 and/or root directory 14. As will be appreciated by those of skill in the art, converting an ABI package to a class archive package of the present invention is easily reduced to a procedure such that all, or some of the above-described steps 6, 7 and 8 can be automated. Without limitation thereto, exemplary uses of the present invention include use by a software developer to ship a package containing encrypted software data, and/or use by a software developer to data-compress a large package so as to be able to fit the package onto a floppy disk for delivery to the market. In accordance with the invention, these end results are achieved by adding one or more install class action scripts 18 to the FIG. 2 scripts portion 16 of ABI install directory 15. Install class action scripts 18 of the present embodiment comprise an extension of the SYSTEM V ABI. In the present embodiment, install class action scripts 18 are not required in the ABI format. However, if an install class action script 18 is present, it will be executed by the SYSTEM V pkgadd utility as is appropriate. FIG. 3 is a flowchart showing operation of the present invention. As will be apparent, the invention uses the well-known UNIX System V class mechanism or method to install all items provided destinations in a destination list from a file, or files, that are of arbitrary construction. As is well known, the SYSTEM V utility pkgadd operates to install, and verify or validate all classes and source files that are within a package. The standard System V validate function 39 of FIG. 3 uses information that is contained in FIG. 2's pkgmap 12. This prior type operation of pkgadd is provided by the operation of functions 31,32,33,34,39 shown in FIG. 3. That is, (1) as long as the package being installed to the UNIX SYSTEM V computer includes another class to process, as is indicated by the yes output of decision function 31, (2) as long as all class source files are validated, as is indicated by the yes output 50 of decision function 32, (3) all files in the class are organized into a list of source and destination pairs by function 33 (shown in detail in FIG. 4), (4) each source is copied to its destination by operation of function 34, and (5) function 39 operates to validate all aspects of the installed class. After the installed class is fully validated by function 39, the FIG. 3 process repeats relative to the next class. When decision function 31 determines that no class remains to be processed, its no output 38 ends software installation process as indicated at 40. As is well known, if validation decision function 32 is not satisfied (i.e., if all source files of the class are not verified), the no output 90 of decision function 32 ends package installation, as is indicted at 40. The above-described prior operation of the UNIX System V pkgadd utility required that all files be plain-text (i.e., unencrypted) and uncompressed, primarily due to the need to validate all source files by function 32. The present invention allows files to be encrypted and/or compressed, as will be apparent. Whenever decision function 41 determines that the keyword PKG_SRC_NOVERIFY has been set for the class, an indication is provided that the class being processed is a special class, this being the required keyword that is used to indicate a special class. In this case, the yes output 42 of function 41 enables decision function 43 to; determine if the keyword PKG_CAS_PASSRELATIVE is also set for the class. The keyword PKG_SRC_NOVERIFY that is looked for by decision function 41 allows a software manufacturer to label a class1 as a special class that is not in the standard UNIX System V format. As stated previously, of the three keywords utilized by the present invention, only the keyword PKG_SRC_NOVERIFY that is checked by decision function 41 is an absolute requirement for implementing a class archive package in accordance with the present embodiment, use of the other two keywords is desirable in order to increase installation speed and/or to conserve code. First it will be assumed that the no output 44 of decision function 43 indicates that the PKG_CAS_PASSRELATIVE is not set for the class. In this case, the FIG. 4 file organization process 33 is performed. Since a class action script 18 is present for this class, output 45 of decision function 37 now enables function 46. That is, the class action script 18 is executed. The class action script 18 is passed the list that is produced by function 33. This list comprises an input to the class action script and in this case, the list is constructed by operation of FIG. 4. Next, it will be assumed that the yes output 47 of decision function 43 indicates that the keyword PKG_CAS_PASSRELATIVE is set for this class. In this case, the FIG. 5 file organization process 48 is performed, whereupon above-mentioned function 46 is enabled. As before, when decision function 31 determines that no class remains to be processed, the no output 38 of decision function 31 enables ending of the package installation process, as indicated at 40. At the conclusion of function 46, decision function 92 operates to determine the level of validation that is desired for this class, now an installed class. If the keyword PKG_DST_QKVERIFY is set for this class, yes output 91 from decision function 92 enables function 94 to validate only the essential parts of this installed class. If this keyword is not set, then no output 93 of decision function 92 enables the standard System V validation function 39 which operates to validate all aspects of each installed file, some aspects of which may have already been validated by the class action script 18 during operation of function 46. In Summary: (1) when a class action script 18 of the present invention is not present for a class that is being installed, function 32 checks to determine if all class source files have been validated, the FIG. 4 process 33 operates to organize the files of the class, each source file is copied to its destination by operation of function 34, and function 39 operates to validate all aspects of the installed class, (2) when a class action script 18 of the present invention is present for a class that is being installed, wherein the keyword PKG_SRC_NOVERIFY is set, but the keywords PKG_CAS_PASSRELATIVE and PKG_DST_QKVERIFY are not set, validation checking function 32 is skipped, function 33 operates to organize the files of the class, function 46 operates to execute the class action script that is associated with the class being installed, and function 39 operates to validate all aspects of the installed class, (3) when a class action script 18 of the present invention is present for a class that is being installed, wherein the keywords PKG_SRC_NOVERIFY and PKG_CAS_PASSRELATIVE are set, but the keyword PKG_DST_QKVERIFY is not set, validation checking function 32 is skipped, function 48 operates to organize the files of the class, function 46 operates to execute the class action script that is associated with the class being installed, and function 39 operates to validate all aspects of the installed class, and (4) when a class action script 18 of the present invention is present for a class that is being installed, wherein the keywords PKG_SRC_NOVERIFY and PKG_DST_QKVERIFY are set but the keyword PKG_CAS_PASSRELATIVE is not set, validation checking function 32 is skipped, function 33 operates to organize the files of the class, function 46 operates to execute the class action script that is associated with the class being installed, and function 39 operates to validate all aspects of the installed class, and, (5) when a class action script 18 of the present invention is present for a class that is being installed, wherein all three of the keywords PKG_SRC_NOVERIFY, PKG_CAS_PASSRELATIVE and PKG_DST_QKVERIFY are set, validation checking function 32 is skipped, function 48 operates to organize the files of the class, function 46 operates to execute the class action script that is associated with the class being installed, and function 94 operates to validate only the essential aspects of the installed class. Utility of the present invention is apparent to those skilled in the art when special installation procedures, such as decompression and decryption, are considered. Without operation of the class action script 18 of the present invention, the SYSTEM V pkgadd utility is incapable of performing such special installation procedures due to the requirement to check the validation of all class source files, as provided by decision function 32 of FIG. 3. In accordance with the present embodiment, execution of class action script 18 provides special functions, such as decompression and decryption of the package prior to installation. FIG. 4 is a flowchart showing the organize-all-files-in-a-class function 33 of FIG. 3; i.e., the operation of the present invention when the PKG_CAS_PASSRELATIVE keyword is not present, or set in an install class action script 18 of the present invention, as is indicated by no output 44 from FIG. 3's decision function 43. The start of the FIG. 4 process is indicated by a numeral 50 that is common to FIGS. 3 and 4. Decision function 51 first operates to determine if there is another package file to be processed. If not, then no output 52 returns operation to decision function 37 of FIG. 3, as is indicated at 52. If a yes output 53 is provided, then decision function 54 is enabled to determine if the package file is in the class being processed. A no output 55 from decision function 54 enables function 56 to select the next package file, whereupon operation returns to decision function 51, as is indicated at 517. A yes output 58 from decision function 54 enables function 59 to derive source and destination from FIG. 2's pkgmap 12, followed by enabling of function 60 to write the source and destination to the file list. Once operation of function 60 has been completed, output 61 enables function 56 to select the next package file, and operation returns to decision function 51, as indicated at 57. FIG. 5 is a flowchart showing the organize-all-files-in-a-class function 48 of FIG. 3; i.e., operation of the present invention when the keyword PKG_CAS_PASSRELATIVE is present or set in the install class action script 18 of FIG. 2, as is indicated by yes output 47 of FIG. 3's decision function 43. The start of the FIG. 5 process is indicated at 47. As the first operation, decision function 70 determines if the list file is initialized. When no output 71 is present, function 72 is enabled to write the path to archive directory 17 of FIG. 2 to the list file, whereupon decision function 73 is enabled. Yes output 74 from decision function 70 directly enables decision function 73. Decision function 73 determines is there is another package file to be processed. If not, then no output 74 returns operation to function 46 of FIG. 3. Yes output 75 from decision function 73 enables decision function 76 to determine if the package being processed is in the class being processed. If no, then output 77 enables function 78 to select the next package file, and the process of FIG. 5 returns to decision function 70, as indicated at 79. Yes output 80 from decision function 76 enables function 81 to derive a destination path from FIG. 2's pgkmap 12, whereupon function 82 is enabled to write the destination to the list file. Output 83 from function 82 then operates to cause function 83 to select the next package file, whereupon the FIG. 5 process returns to decision function 70. A utility can be used to convert from the FIG. 1 UNIX SYSTEM V ABI format to the FIG. 2 UNIX SYSTEM V ABI format in accordance with the present invention. An example utility archives using the cpio utility, and compresses using the compress utility. This sample utility can also be used to construct a package that uses a different archival, and/or compression method than cpio and compress. With reference to FIGS. 1 and 2, given a standard ABI style package 10 that contains several classes, including class1 and class2 which are to be archived, the following multi-step method represents the preferred operation of the utility to convert the standard ABI package into a class archive format of the present invention. Step (1)--An alphabetic list of pkgmap 12 entries of ftype `f` and `v` which belong to class1 and class2, respectively, are established; i.e., two lists of ordinary files, one for class1 and one for class2. Step (2)--Two archives are created and placed in archive directory 17 under names that can be mapped back to the class; in this case, the names `class1` and `class2`. Step (3)--Delete all class1 and class2 files from reloc directory 13 and root directory 14. Step (4)--Delete all empty directories from reloc directory 13 and root directory 14, including deletion of reloc directory 13 and root directory 14 themselves if everything is archived. Step (5)--Modify pkginfo file 11, example entries being: PGK_SRC_NOVERIFY=class1 class2 PKG_QKVERIFY=class1 class2 PGK_CAS_PASSRELATIVE=class1 class2 Step (6)--Add class action scripts 18 named i.class1 and i.class2 to install directory 15. Step (7)--Modify pkgmap file 12 by correcting the recorded attributes of pkginfo 11 as they were modified in step 5, and add the correct compressed size to the first line of pkgmap 12. As is apparent from the detailed description of this invention, operation of the present invention preserves the original System V functionality for a software package, while at the same time establishing an open interface definition for the delivery of compressed/encrypted packages. The specific details of the utility tools that are used to translate an ABI software package into a form that is defined by the class archive package of the present invention are not critical to the invention, and such utility tools may be those soon to be made generally available to the public from SUN MICROSYSTEMS. An example of a utility that is used to archive a specific class in an ABI-style package, in order to convert that package to a class archive format package of the present invention, will now be described. The caller of the utility directs the utility to a custom archive script that is separate from the package that is responsible for creating a custom archive in the archive directory 17 of the package. That is, this utility operates to convert packages to/from class archive format. The above mentioned custom archive script (arch_script) is written by the package producer as a part of the package design. It is preferably called with the following arguments. $1="archive" if the "-u" option was not used, "dearchive" otherwise. $2=archive directory 17 in the package. $3=class name $4=(archive only) file containing list of files to archive. The following archive-script operates to archive or dearchive all files in the stated class using the standard UNIX utility cpio.
# $1 = "archive", $2 =archive directory, $3 =
class name, $4 # = list of files in class
Archive=${2}/${3}
if [ $1 = "archive" ]; then
cpio -oc -O $archive < $4
chmod 0644 $Archive
exit O
fi
# $1 = "dearchive", $2 = archive directory $3 =
class name
# $4 = list of files in the class
if [ $1 = "dearchive" ]; then
cpio -idukm -I $Archive
if [ $? -eq O ]; then
rm -r $Archive
exit O
else
exit $?
fi
fi
As is well known to those of skill in the art, the published requirements of UNIX System V ABI, and the SUN MICROSYSTEMS publication entitled "Application Packaging Developer's Guide", incorporated herein by reference, permit the procedure-scripts portion of scripts 16 to accomplish many different functions. Following is a list of the basis requirement for making a class archive package in accordance with this embodiment. (1) Generally there must be only one class per archive file. That is, no archive may contain files from more than one class. However, two or more archives per class are permissible under special circumstances, as noted below at requirement (5). (2) Class action script 18 that is associated with the archived class of directory 17 unpacks only those files from archive that are provided to class action script 18 through the standard input (stdin). An exception to this process is when the environment variable PKG_INIT_INSTALL is defined. In this latter case, the stdin file list can be ignored as long as everything in the archived class is unpacked and installed. (3) Pkgmap 12 contains the correct size and checksum for all class action scripts 18 that are to be verified by pkgadd. Note that it is not required that pkgadd verify class action script 18 itself. (4) Pkginfo 11 contains a PKG_SRC_NOVERIFY keyword entry for each class that is to be archived in archive directory 17. (5) Due to the steps outlined in (2) above, it is generally not practical to include more than 500 entries in archive directory 17. This is one reason that requirement (1) above allows more than one class per archive file. In order to speed-up the selective extraction from a large set of archived files from archive directory 17, it is possible for a file class having 2,000 items to be split across four archives. In this case, each archive will hold some ordered subset of 500 entries. Class action script 18 now takes responsibility for selecting the correct archive, based upon the list of items to extract. A reasonable approach for extracting relative paths is to write a class action script 18 in such a way that it will "cd" to the directory that is indicated by the environment variable ${BASEDIR}, and then unpack the archive. If absolute pathnames are archived from the package's root directory 14, the leading "/" is stripped from the absolute path, and archive is performed as a relative path. Class action script 18 will now "cd" to the directory that is indicated by ${PKG_INSTALL_ROOT:-/} before unloading the archive. Thus, permitting installation to clients from a server. The file list that is passed to class action script 18 is preferably used to extract only those specified files from archive. An absolute path list that is passed for extraction will be edited before passing it to the archival utility; i.e., the absolute path will be stripped of it's leading "/". It is permissible to have two archives that represent the reloc 13 and root 14 components of a single class, as long as they can be identified by their class action script 18, and as long as both components can be unpacked by that single script 18, given a single list of absolute and relative pathnames. Following is a sample class archive class action script 18 in accordance with this embodiment. # This class action script is preferably executed within a Bourne shell # by pkgadd.
NAME="i.none"
FILELIST=${PKGSAV:?undefined}/filelist
BD=${BASEDIR:-/}
is_an_archive=0
is_a_filelist=0
list_empty=1
local_install=0
Spcl_init=0
Rm_alt_sav=0
Tmp_xpath=/usr/tmp$$dir
MV_path=/usr/sbin/static
MV_cmd_$MV_xpath/mv
CPIO_xpath=/usr/bin
CPIO_cmd=$CPIO_xpath/cpio
ZCAT_xpath=/usr/bin
ZCAT_cmd=$ZCAT_xpath/zcat
LN_xpath=/usr/bin
LN_cmd=$LN_xpath/ln
NAWK_xpath=/usr/bin
NAWK_cmd=$NAWK_xpath/nawk
RM_xpath=/usr/bin
RM_cmd=$RM_xpath/rm
eval_pkg( ) {
# Get the package source directory.
read path
if [ ${path:-NULL} !=NULL ] : then
PKGSRC=${path:?undefined}
# Look for the archive (it may or may
not be
# compressed) .
if [ -r $PKGSRC/archive/none.Z ] ; then
-r $PKGSRC/archive/none.Z ] ; then
is_an_archive
fi
else
exit 0# empty pipe, we're done
fi
}
# main part of script.
eval-pkg
if [ $is_an_archive -eq 0] ; then
echo "ERROR : i.none cannot find archived
files in $PKGSRC/archive."
exit 1
fi
# This script works only with relocatable paths.
Reloc_Arch=$PKGSRC/archive/none
# Now find the save directory for our extension
list.
if [ ! -d $PGKSRC ] : then
echo "WARNING : i.none cannot find save
directory $PKGSAV."
PKGSAV=$tmp_xpath/$PKG.sav
if [ ! -d $PKGSAV ] ; then
/usr/bin/mkdir $PGKSAV
fi
if [ $? -eq 0] ; then
echo "Using alternate save directory."
$PKGSAV
FILELIST-$PKGSAV/filelist
Rm_alt_sav=1
else
echo "ERROR : cannot create alternate
save directory." $PGKSAV
exit 1
fi
# If there is already an extraction list,
delete it.
if [ -f $FILELIST ] ; then
rm $FILELIST
fi
# GO to base directory.
cd $BD
# If this isn't an actual install, construct
the # extraction list.
if { ${PKG_INIT_INSTALL: -null} = null ] ; then
is_a_filelist=1
whileread path
do
echo $path >> $FILELIST
list_empty=0
done
fi
# Extract the archive.
if [ $is-a-filelist -eq 1 ] ; then
if [ $list_empty -eq 0 ] ; then
$ZCAT_cmd $Reloc_arch
$CPIO_cmd -idukm -E $FILELIST
if [ $? -ne 0 ] ; then
echo "cpio of $reloc_arch failed with
error $?."
exit 1
fi
fi
else
$ZCAT_cmd $Reloc_Arch
$CPIO_cmd -idukm
fi
if [ -f $FILELIST ] : then
$RM_cmd $FILELIST
fi
if [ $Rm_alt_sav -eq 1 ] ; then
$RM_cmd -r $PKGSAV
fi
exit 0
The following is an example of the content of a class archive pkginfo file 11 that is written to test the functionality of class archive in accordance with the present embodiment. PKG=TSTPclrc1 NAME=class archive package ARCH=i386 VERSION=1.0 PRODNAME=SunOS MAXINST=1000 CATEGORY=system DESC=Sample package for testing class archive functionality VENDOR=Test group EMAIL= CLASSES=none group spcldrv PKG_SRC_NOVERIFY=none PKG_DST_QKVERIFY=none PKG_CAS_PASSRELATIVE=none BASEDIR=/opt/clrcdemo The operating environment, in which the present invention is used, encompasses the general distributed computing system, wherein general purpose computers, workstations, or personal computers are connected via communication links of various types, in a client-server arrangement, wherein programs and data, many in the form of objects, are made available by various members of the system. Examples of general distributed computing systems include SPARC systems offered by Sun Microsystems, Inc., client-server systems configured from personal computers offered by IBM Corporation and by other manufacturers of IBM-compatible personal computers, and systems running the UNIX operating system. Some of the elements of a general purpose workstation computer are shown in FIG. 6, wherein a processor 1 is shown, having an input/output (I/O) section 2, a Central Processing Unit (CPU) 3 and a memory section 4. The I/O section 2 is connected to a keyboard 5, a display unit 6, a disk storage unit 9 and a CD-ROM drive unit 7. The CD-ROM unit 7 can read a CD-ROM medium 8 which typically contains programs 10 and data. The computer program products containing mechanisms to effectuate the apparatus and methods of the present invention may reside in the memory section 4, or on a disk storage unit 9, or on the CD-ROM 8 of such a system. The invention has been described in detail while making reference to preferred embodiments thereof. It will be appreciated that those skilled in the art will, upon learning of this invention, readily visualize yet other embodiments that are within the spirit and scope of this invention. Thus, this detailed description is not be taken as a limitation on this invention.
|
Same subclass Same class Consider this |
||||||||||