U.S. patent application number 12/435330 was filed with the patent office on 2009-10-29 for mechanism for determining applicability of software packages for installation.
Invention is credited to John R. Chang, Jean-Pierre Ciudad, Gregory Novick.
Application Number | 20090271782 12/435330 |
Document ID | / |
Family ID | 40585033 |
Filed Date | 2009-10-29 |
United States Patent
Application |
20090271782 |
Kind Code |
A1 |
Ciudad; Jean-Pierre ; et
al. |
October 29, 2009 |
MECHANISM FOR DETERMINING APPLICABILITY OF SOFTWARE PACKAGES FOR
INSTALLATION
Abstract
Mechanism for determining applicability of a software package
for installation is described herein. In one embodiment, a process
is provided to retrieve authentication information of a component
from an installation descriptor file, where the descriptor file
describes installation information of the software package. The
software package may include one or more components and each
component having zero or more sub-components. For at least one
sub-component of at least one existing component that has already
been installed, an image of the sub-component is authenticated
using an authentication key extracted from the authentication
information to determine whether the component can be installed
based on the existing component. Other methods and apparatuses are
also described.
Inventors: |
Ciudad; Jean-Pierre; (San
Francisco, CA) ; Novick; Gregory; (Santa Clara,
CA) ; Chang; John R.; (Palo Alto, CA) |
Correspondence
Address: |
APPLE INC./BSTZ;BLAKELY SOKOLOFF TAYLOR & ZAFMAN LLP
1279 OAKMEAD PARKWAY
SUNNYVALE
CA
94085-4040
US
|
Family ID: |
40585033 |
Appl. No.: |
12/435330 |
Filed: |
May 4, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10918614 |
Aug 13, 2004 |
7530065 |
|
|
12435330 |
|
|
|
|
Current U.S.
Class: |
717/174 ;
717/168; 717/171; 717/175; 717/176 |
Current CPC
Class: |
G06F 8/60 20130101 |
Class at
Publication: |
717/174 ;
717/168; 717/171; 717/175; 717/176 |
International
Class: |
G06F 9/445 20060101
G06F009/445 |
Claims
1.-36. (canceled)
37. A method for installing a software package, the method
comprising: downloading from a server over a network a package
metadata (PKM) file describing installation of the software package
without downloading the software package, the software package
including one or more components and each of the components having
zero or more sub-components; authenticating an image of at least
one sub-component of at least one existing component from which the
software package is installed, wherein the authentication is
performed using a first key retrieved from the PKM file; and
downloading at least a portion of the software package from the
server to be installed if the image of the at least one
sub-component is authenticated successfully using the first key
retrieved from the PKM file.
38. The method of claim 37, wherein the PKM file is an extensible
markup language (XML) compatible file.
39. The method of claim 37, wherein the first key comprises a
checksum value of the at least one sub-component of the existing
component, and wherein the authentication includes a checksum
operation using the checksum value to authenticate the existing
component.
40. A method for installing a software package, the method
comprising: retrieving authentication information of a component
from an installation descriptor file describing installation
information of the software package the software package having one
or more components; and determining authenticity of an image of at
least one existing component that has already been installed using
a first key extracted from the authentication information, to
determine whether the component can be installed based on the
existing component.
41. A method for installing a software package having a plurality
of components on a computer system, the method comprising:
downloading from a server over a network metadata describing the
plurality of components of the package without downloading the
components; determining, using at least a portion of the metadata,
whether any of the components are already installed on the computer
system; determining, based at least in part on determining whether
any of the components are already installed on the computer system,
which of the components should be downloaded to the computer system
for installation.
Description
[0001] This application is a continuation of co-pending U.S. patent
application Ser. No. 10/918,614, filed on Aug. 13, 2004.
FIELD OF THE INVENTION
[0002] The present invention relates generally to computer systems.
More particularly, this invention relates to mechanism for
determining applicability of software packages for
installation.
BACKGROUND OF THE INVENTION
[0003] Most popular software products nowadays constantly go
through revisions to fix "bugs" or add new features and
functionality. To that end, each revision of a software product or
component may require the addition of new files, the replacement of
existing files with newer versions of files, and/or removal of a
file. Once a vendor has isolated a software product problem and
created a solution for the problem, they would want to put that fix
into an update and make the update widely available to the
customers. Software vendors have a business incentive to distribute
software updates to customers as quickly and trouble-free as
possible.
[0004] The Internet provides a channel for customers to obtain the
latest updates for software products. The vendor sites on the
Internet can be designed to make it very simple to discover and
locate updated files for an application. The technical aspects of
file downloading have mostly disappeared from the user's view, and
are now typically handled by the operating system.
[0005] To minimize the size of the updates over the Internet,
software companies utilize file patches, which contain only the
changes that must be made to pre-existing files, rather than the
whole files themselves. A patch assumes that the original file on
the target system is of a specific state. "Patching" applies
changes to that file to bring the file to a desired, usually newer,
state. However, the file should be verified to be in the required
condition. Otherwise, the patch may be incorrectly applied and the
file may be damaged. If a file to be patched is in an unexpected
state, the patch cannot be applied. In addition, if the client
machine has a sub-component that has a newer version than the one
about to be upgraded, a conventional installation may abort the
whole installation, even though there might be other sub-components
that have older versions.
SUMMARY OF THE INVENTION
[0006] Mechanism for determining applicability of software packages
for installation is described herein. In one embodiment, a process
is provided to retrieve authentication information for a component
from an installation descriptor file, where the descriptor file
describes installation information pertaining to the software
package. The software package may include one or more components
and each component having zero or more sub-components. For at least
one sub-component of at least one existing component that has
already been installed, an image of the sub-component is
authenticated using an authentication key extracted from the
authentication information, to determine whether the component can
be installed based on the existing version of the component.
[0007] Other features of the present invention will be apparent
from the accompanying drawings and from the detailed description
which follows.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] The present invention is illustrated by way of example and
not limitation in the figures of the accompanying drawings in which
like references indicate similar elements.
[0009] FIG. 1 is a diagram of a network of computer systems in
which one or more clients may download and install a software
package from a server.
[0010] FIG. 2 is a block diagram illustrating an exemplary
component descriptor of an installation descriptor file according
to one embodiment of the invention.
[0011] FIG. 3 is a timeline illustrating a version timeline of a
software package upgrade according to one embodiment.
[0012] FIG. 4 is a flow diagram illustrating an exemplary process
for installing a software package according to one embodiment of
the invention.
[0013] FIG. 5 is a block diagram illustrating an exemplary
document-type definition (DTD) file of an installation descriptor
according to one embodiment of the invention.
[0014] FIGS. 6A-6D are an example of an installation descriptor
file written in XML according to one embodiment of the
invention.
[0015] FIG. 7 is a flow diagram illustrating an exemplary process
for installing a software package according to one embodiment of
the invention.
[0016] FIG. 8 is a flow diagram illustrating an exemplary process
for installing a software package according to another embodiment
of the invention.
[0017] FIG. 9 is a flow diagram illustrating an exemplary process
for installing a software package according to another embodiment
of the invention.
[0018] FIG. 10 is a block diagram of a digital processing system,
which may be used with one embodiment of the invention.
DETAILED DESCRIPTION
[0019] Mechanism for determining applicability of software packages
for installation is described herein. According to one embodiment,
an installation package is optimized by size, containing a
combination of patches and/or full files. Installation of the
package ensures that the user will have at least the version of the
software included in the package. In one embodiment, the content of
an installation package includes patches for some files and/or full
versions of some other files, dependent upon the
configurations.
[0020] In one embodiment, the package further includes a package
description file, which may be used by an installer to determine
whether the installation package can be installed. The package
description file, also referred to as installation descriptor file
or a package metadata (PKM) file, describes the contents of the
installation package with sufficient details to allow the
installation system to determine whether the software package can
be installed on a client system.
[0021] In addition, the PKM file further includes one or more
components and each component includes zero or more files (e.g.,
sub-components or child components). The files to be updated or
added to the client system are divided into distinct,
non-overlapping components. The information contained in the PKM
file about the individual files is grouped by component.
[0022] Further, according to one embodiment, two types of
versioning may be used: component version for some of the
components and authentication information for authenticating or
determining authenticity of at least some of the files for each
component. In one embodiment, there may be two versions specified
for at least some of the components that have patched files in the
distribution. The first version is the version of the component
that is expected to be on the client system prior to applying the
patches, also referred to as a pre-install version. The second
version is the version of the component that the client system will
contain after the patches are applied, also referred to as a
post-install version. Alternatively, more or less versions may be
implemented.
[0023] In one embodiment, the authentication information includes
at least one authentication key, which may be used to authenticate
a file image of at least some files of a component or
alternatively, to authenticate the component itself. In a
particular embodiment, the authentication key may include a
checksum value and the authentication operations may include a
checksum operation. In a further embodiment, the authentication
information includes a pre-install authentication key and a
post-install authentication key. The pre-install authentication key
may be used to authenticate the pre-existing file corresponding to
the file being installed. The post-install authentication key may
be used to verify whether a particular file has already been
installed. Similarly, the pre-install and post-install
authentication keys may be checksum values (e.g., pre-install and
post-install checksum values).
[0024] In the following description, numerous details are set forth
to provide a more thorough explanation of the present invention. It
will be apparent, however, to one skilled in the art, that the
present invention may be practiced without these specific details.
In other instances, well-known structures and devices are shown in
block diagram form, rather than in detail, in order to avoid
obscuring the present invention.
[0025] Some portions of the detailed descriptions which follow are
presented in terms of algorithms and symbolic representations of
operations on data bits within a computer memory. These algorithmic
descriptions and representations are the means used by those
skilled in the data processing arts to most effectively convey the
substance of their work to others skilled in the art. An algorithm
is here, and generally, conceived to be a self-consistent sequence
of steps leading to a desired result. The steps are those requiring
physical manipulations of physical quantities. Usually, though not
necessarily, these quantities take the form of electrical or
magnetic signals capable of being stored, transferred, combined,
compared, and otherwise manipulated. It has proven convenient at
times, principally for reasons of common usage, to refer to these
signals as bits, values, elements, symbols, characters, terms,
numbers, or the like.
[0026] It should be borne in mind, however, that all of these and
similar terms are to be associated with the appropriate physical
quantities and are merely convenient labels applied to these
quantities. Unless specifically stated otherwise as apparent from
the following discussion, it is appreciated that throughout the
description, discussions utilizing terms such as "processing" or
"computing" or "calculating" or "determining" or "displaying" or
the like, refer to the action and processes of a computer system,
or similar electronic computing device; that manipulates and
transforms data represented as physical (electronic) quantities
within the computer system's registers and memories into other data
similarly represented as physical quantities within the computer
system memories or registers or other such information storage,
transmission or display devices.
[0027] The present invention also relates to apparatus for
performing the operations herein. This apparatus may be specially
constructed for the required purposes, or it may comprise a general
purpose computer selectively activated or reconfigured by a
computer program stored in the computer. Such a computer program
may be stored in a computer readable storage medium, such as, but
not limited to, any type of disk including floppy disks, optical
disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs),
random access memories (RAMs), erasable programmable ROMs (EPROMs),
electrically erasable programmable ROMs (EEPROMs), magnetic or
optical cards, or any type of media suitable for storing electronic
instructions, and each coupled to a computer system bus.
[0028] The algorithms and displays presented herein are not
inherently related to any particular computer or other apparatus.
Various general purpose systems may be used with programs in
accordance with the teachings herein, or it may prove convenient to
construct more specialized apparatus to perform the required method
steps. The required structure for a variety of these systems will
appear from the description below. In addition, the present
invention is not described with reference to any particular
programming language. Alternatively, a variety of programming
languages may be used to implement the teachings of the invention
as described herein.
[0029] A machine-readable medium includes any mechanism for storing
or transmitting information in a form readable by a machine (e.g.,
a computer). For example, a machine-readable medium includes read
only memory ("ROM"); random access memory ("RAM"); magnetic disk
storage media; optical storage media; flash memory devices;
electrical, optical, acoustical or other form of propagated signals
(e.g., carrier waves, infrared signals, digital signals, etc.);
etc.
[0030] FIG. 1 is a diagram of a network of computer systems in
which one or more clients may download and install a software
package from a server. As shown in FIG. 1, a network 100 includes a
number of client computer systems 101 that are coupled together
through a network 102, for example, an Internet. Alternatively, the
term "Internet" refers to a network of networks. Such networks may
use a variety of protocols for exchange of information, such as
TCP/IP, ATM, SNA, SDI, etc. The physical connections of the
Internet and the protocols and communication procedures of the
Internet are well known to those in the art. Such a system may be
implemented in an Intranet within an organization.
[0031] Access to the Internet 102 is typically provided by Internet
service providers (ISPs). Users on client systems, such as the
client computer systems 101, generally obtain access to the
Internet through Internet service providers. Access to the Internet
may facilitate transfer of information (e.g., email, text files,
media files, etc.) between two or more digital processing systems
and/or a server system 103, which may be a Web server. For example,
one or more of the client computer systems and/or the Web server
may provide document presentations (e.g., a Web page) to another
one or more of the client computer systems and/or Web server.
[0032] For example, in one embodiment of the invention, one or more
client computer systems 101 may request to access a document that
may be stored at a remote location, such as the Web server 103. In
the case of remote storage, the data may be transferred as a file
(e.g., download) and then displayed (e.g., in a window of a
browser) after transferring the file. In another embodiment, the
document presentation may be stored locally at the client computer
systems. In the case of local storage, the client system may
retrieve and display the document via an application, such as a
word processing application, without requiring a network
connection.
[0033] The server 103 typically includes at least one computer
system to operate with one or more data communication protocols,
such as the protocols of the World Wide Web, and as such, is
typically coupled to the Internet 102. Optionally, the server 103
may be part of an ISP which may provide access to the Internet
and/or other network(s) for client computer systems. The client
computer systems 101 may each, with appropriate Web browsing
software, access data, such as HTML documents (e.g., Web pages),
which may be provided by the server 103.
[0034] The ISP provides Internet connectivity to the client
computer system 101 via a network interface, which may be
considered as part of the client computer system. The client
computer systems may be a conventional data processing system, such
as a Power Mac G5 or iMac computer available from Apple Computer,
Inc., a "network" computer, a handheld portable computer, a cell
phone with data processing capabilities, a Web TV system, or other
types of digital processing systems (e.g., a personal digital
assistant (PDA)).
[0035] However, as depicted in FIG. 1, such connectivity may vary
between various client computer systems. For example, the client
computer system 101 may be part of a local area network (LAN). The
network interface of the client 101 may represent an analog modern,
an ISDN modem, a DSL modem, a cable modem, a wireless interface, or
other interface for coupling a digital processing system, such as a
client computer system, to another digital processing system.
[0036] Alternatively, the network interface of client 101 may be an
Ethernet-type, asynchronous transfer mode (ATM), or other type of
network interface, which may couple the client 101 to a local area
network (LAN). The LAN may also be coupled to a gateway digital
processing system, which may provide firewall and other
Internet-related services for a LAN. The gateway digital processing
system, in turn, is coupled to the ISP to provide Internet
connectivity to the client computer systems 101. The gateway
digital processing system may, for example, include a conventional
server computer system. Similarly, the server 103 may, for example,
include a conventional server computer system.
[0037] In one embodiment, server 103 may be a Web server that
provides software upgrade packages, which may include one or more
software packages 109. Alternatively, the server 103 may be file
server of a local network, such as, for example, an Intranet. For
each of the software packages 109, there may be an installer 107
and a PKM file 108 associated with the respective software package.
The installer 107 may be shared by some or all installation of
software packages 109. The installer 107 is capable of reading the
installation description from the respective PKM file and correctly
installs the respective software package.
[0038] When client system 101 requires an upgrade, the client 101
may download the installer 104 and the PKM file 106 corresponding
to the software package being installed. Alternatively, the client
system 101 includes the installer 104 pre-installed when the client
system was manufactured. In which case, the client 101 only needs
to download the PKM file 106. In one embodiment, the installer 104
retrieves installation description from the PKM file 106 to
determine the installation configuration of the respective software
package being installed. The installation description may include
versioning and authentication information, which may be used to
verify one or more existing components and/or files 105 that have
already been installed in the client 101 from which the new patches
or components may be installed.
[0039] In one embodiment, the PKM file 106 includes one or more
component descriptors 110 describing installation of the
corresponding one or more components. Each of the components
described by the descriptors 110 may optionally include version
information 111 associated with the respective component. In
addition, each of the component descriptors may include zero or
more sub-component descriptors 112 describing installation of zero
or more files grouped under the respective component.
[0040] In one embodiment, at least some of the sub-component
descriptors 112 may include a pre-install authentication key 113
and a post-install authentication key 114. The pre-install
authentication key 113 may be used to authenticate the pre-existing
sub-component corresponding to the sub-component being installed.
The post-install authentication key 114 may be used to verify
whether a particular sub-component has already been installed. In a
particular embodiment, pre-install and post-install authentication
keys may be checksum values.
[0041] In one embodiment, a sub-component may be a file associated
with a component. Throughout this application, for the purposes of
illustrations, a file and a sub-component are used interchangeably.
However, they are not so limited. A sub-component, as a parent
component, may further include one or more sub-components (e.g.,
child components).
[0042] According to one embodiment, the installation system uses
the information retrieved from the PKM file 106 to ensure that the
client will have at least the version of each of the software
components included in the installation package when the
installation is completed. Since performing authentication (e.g., a
checksum operation) on a file is a relatively time-expensive
operation, the component version 111 may be used to optimize the
install target verification process.
[0043] For example, if the version of a particular component on the
client system is not what is required for the patch (e.g., the
pre-install version) and it is not the post-install version or
newer (e.g., the updated component has already been installed), the
installer would know by comparing the version of the existing
component and the version retrieved from the PKM file, without
having to perform the authentication on each file of the existing
component, that the client system does not meet the requirement of
the installation package.
[0044] Similarly, if the client system's version of a component is
already the same or newer than the version contained in the package
(e.g., the post-install version), the installation system does not
need to install the files for that component, while allowing the
rest of the installation package to proceed.
[0045] If the installer 104 determines that the version of the
existing component on the client system 101 is the pre-install
version, the installer 104 may further perform the authentication
on each of the sub-components described by the sub-component
descriptors 112 to ensure that the sub-components have not been
tampered with and are of the exact state required by the patch,
using the pre-install authentication information 113.
[0046] If the authentication of the sub-component is not performed
successfully (e.g., the checksum operation does not match with the
corresponding checksum value retrieved from the PKM file 106), the
post-install authentication information 114 may be used to verify
whether the sub-component (e.g., file) being updated has already
been installed in the client system 101. In such a case, the
sub-component does not need to be installed (e.g., skipping). On
the other hand, if the post-install authentication is not performed
successfully, the patch cannot be applied to the client system 101
and the installation of the entire software package should not be
allowed.
[0047] In one embodiment, the PKM file 106 and/or installer 104 are
initially downloaded from the server 103 to the client system 101
without downloading the actual software package 109 being
installed. With the PKM file 106, the installer 104 is capable of
determining whether the software package (e.g., the patches) can be
installed on the client system 101, or alternatively, a full
installation of the software may be needed. Once the installer 104
determines that the software package may be installed based on the
existing components and/or files 105, the installer 104 may
download the necessary patch files (e.g., only those that would be
installed) from the server 103 to install the patches.
Alternatively, according to another embodiment, if the installer
determines that the existing components and/or files 105 of the
client 101 cannot be patched (e.g., only certain files need to be
updated), the installer 104 may download the full installation
image of the software (e.g., full version) and perform a complete
installation of the software, which consumes more time and
resources.
[0048] According to another embodiment, the PKM file 108 may
provide additional information regarding other portions of the
package that are located on other media. For example, if a
particular software distribution is packaged on multiple CDs, the
PKM file of the first CD may provide information regarding the
files stored in the subsequent CDs. At the beginning of the
installation, a user can choose which of the packages she would
like to install from the subsequent CDs without having to insert
the subsequent CDs, where the installer can simply read the PKM
files for those packages existing elsewhere.
[0049] It will be appreciated that server 103 may include multiple
servers separated from each other. Some or all of the components
107-109 may be located on different servers. For example, the
installer 107 and the PKM files 108 may be downloaded from a first
server. After the installer 107 determines, based on the PKM files
108, which patches may be installed at a client machine, the actual
patches to be installed may be downloaded from a second server.
Other configurations may exist.
[0050] FIG. 2 is a block diagram illustrating an exemplary
component descriptor of an installation descriptor file according
to one embodiment of the invention. The exemplary component
descriptor 200 may be implemented, for example, as a component
descriptor 110 of FIG. 1. Referring to FIG. 2, exemplary component
200, also referred to as a bundle, includes a default path 201
indicating where the component is being installed. The exemplary
component 200 also includes a bundle information block 202 to
specify the specific information associated with the respective
bundle. In one embodiment, the information block 202 includes an
identifier 204 for identifying the respective bundle, a bundle
version 205 indicating the version of the bundle being installed
and a pre-bundle version of an existing bundle on top of which the
new bundle is to be installed.
[0051] The exemplary component 200 further includes files block 203
having zero or more files 207-208 (e.g., sub-components). Each of
the files 207-208 may include a path 209 and 211 respectively to
specify where the file will be installed and authentication keys
210 and 212 to provide authentication information; including
pre-install and post-install authentication keys to the installer
to perform authentication operations.
[0052] FIG. 3 is a timeline illustrating a version timeline of a
software package upgrade according to one embodiment. In this
embodiment, the exemplary timeline 300 includes a software package
having a component with newer version 302 that is intended to be
installed on a system with previous version of an existing
component 301. That is, the component having version 302 is
intended to be installed on a client machine that already has a
previous component having version 301. If the existing component
has any other version between the versions 302 and 301, such as,
for example, version 307, the installation of the component (e.g.,
the upgrade) would not be allowed.
[0053] Referring to FIG. 3, the installer opens and parses a PKM
file to identify each of the components being installed. If the
respective component is a versioned component (e.g., the component
has a specific version, which may be described in a version block
such as version block 111 of FIG. 1), the installer examines the
version of the corresponding existing component. If the version of
the existing component is the same or newer than the version of the
component that is about to be installed, in this case, situation
303, the component does not need to be installed and the
installation of the component will be skipped.
[0054] If the version of the existing component is the same as the
pre-install version retrieved from the PKM file (e.g., the existing
component is the targeted component from which the new component
will be installed), in this case, situation 304, the installer may
further authenticate at least one of the sub-components of the
existing component using the pre-install authentication information
retrieved from the PKM file. If the authentication is performed
successfully, the new component will be installed based on the
existing component. Otherwise, the installation may be aborted.
Similarly, if the version of the existing component is older than
the pre-install version (e.g., situation 306) or between the
pre-install version and the post-install version, such as version
307 (e.g., situation 305), the installation may be aborted.
[0055] FIG. 4 is a flow diagram illustrating an exemplary process
for installing a software package according to one embodiment of
the invention. Exemplary process 400 may be performed by a
processing logic that may comprise hardware (circuitry, dedicated
logic, etc.), software (such as is run on a dedicated machine), or
a combination of both. For example, the exemplary process 400 may
be performed by an installer using a PKM file, such as, for
example, installer 104 using PKM file 106 of FIG. 1.
[0056] In one embodiment, exemplary process 400 includes, but is
not limited to, downloading from a server over a network a package
metadata (PKM) file describing installation of the software package
without downloading the software package. The software package
including one or more components and each of the components having
zero or more sub-components, authenticating an image of at least
one sub-component of at least one existing component from which the
software package is installed, wherein the authentication is
performed using a first key retrieved from the PKM file, and
downloading at least a portion of the software package from the
server to be installed if the image of at least one sub-component
is authenticated successfully using the first key retrieved from
the PKM file.
[0057] Referring to FIG. 4, at block 401, a PKM file is downloaded
from a server over a network. In one embodiment, an installer
application (e.g., installer 104 of FIG. 1) may also be downloaded
with the PKM file. The PKM file may provide sufficient information
describing the installation of a software package being installed.
The software package may include one or more components (e.g.,
bundles) and each component may include zero or more files. The PKM
file may be a metadata file written in a variety of programming
languages, such as, for example, XML and HTML (hypertext markup
language). In one embodiment, the actual software package has not
been downloaded yet at this point. The PKM file may be downloaded
over the Internet from a Web server using a variety of protocols,
for example, TCP/IP protocols. Alternatively, the PKM file may be
downloaded from a server within a local network (e.g., the Intranet
or LAN).
[0058] At block 402, for at least one file of at least one
component of the software package, the authentication information
associated with the respective file is retrieved from the PKM file.
The authentication information may be used to authenticate an image
of an existing sub-component (e.g., file) of an existing component
to determine whether a new version of the component may be
installed on the basis of the existing sub-component of the
existing component. In one embodiment, the authentication
information includes an authentication key for authenticating the
sub-component.
[0059] At block 403, an authentication operation is performed on
the existing sub-component of the existing component that has
already been installed in a client machine, using the
authentication information retrieved from the PKM file, for
example, an authentication key. In one embodiment, the
authentication key may include a checksum value and the
authentication operation includes a checksum operation performed on
the sub-component using the checksum value.
[0060] If the authentication is performed successfully, at block
404, the actual sub-components and/or the respective component may
be downloaded from the server and installed in the client machine.
In an alternative embodiment, if the authentication is performed
unsuccessfully, a full installation image of the software package,
rather than patches, may be downloaded and the full installation
may be invoked.
[0061] FIG. 5 is a block diagram illustrating an exemplary
document-type definition (DTD) file of an installation descriptor
according to one embodiment of the invention. An example of an
installation descriptor written in XML is shown in FIGS. 6A-6D
according to certain embodiments of the invention. However the
installation descriptor is not limited to XML. It will be
appreciated that other languages, such as, for example, HTML
(hypertext markup language) may also be used.
[0062] Referring to FIGS. 5 and 6A-6D, exemplary DTD 500 includes a
package information tag 501 for describing general information
regarding the software package being installed. For example, among
other information, the package information 501 may include an
identifier tag 502 to provide an identifier for identifying the
software package being installed. In one embodiment, the identifier
specified by the identifier tag 502 may be a unique identifier
specifically identifying the package. An example of a package
information block and the identifier tag in XML are shown as
package information block 601 and identifier 602 in FIG. 6A.
[0063] The exemplary DTD 500 may also include a version block 503.
An example of a version block is shown as version block 603 in FIG.
6A. In one embodiment, the version of the software package being
installed may include at least one of a short version, a major
version, a minor version, a build version, and/or a build date.
Other version related information may be included.
[0064] The exemplary DTD 500 may also include one or more flags
which may be implemented within a flag block 504. An example of a
flag block is shown as a flag block 604 in FIG. 6A. In one
embodiment, a variety of flags may be implemented within the flag
block 504. For example, there may be a flag that indicates whether
the client system has to restart after the installation of the
package.
[0065] In addition, according to one embodiment, the exemplary DTD
500 includes a component block (e.g., a component array) 505 that
may include one or more components 506. Each of the components may
or may not include one or more sub-components 513, for example, one
or more sub-components grouped under the respective component. For
example, the exemplary installation descriptor 600 shown in FIGS.
6A-6D includes components 606 and 621-622, which may include zero
or more sub-components respectively. In the example shown in FIGS.
6A-6D, component 606 includes sub-components 614 and 620, and
component 622 includes sub-components 623-625. In a further
embodiment, certain sub-components may further include their
respective sub-components (e.g., child components).
[0066] Referring back to FIG. 5, each component 506 may include a
component information tag 507 and an identifier tag 508. An example
of a component information block and an identifier tag are shown as
tags 607 and 608 in FIG. 6B. In one embodiment, the component
identifier includes a string that uniquely identifies a component
(e.g., a bundle) of a client machine. This information may be found
in a predetermined location of the client machine and may be hidden
from a user of the client machine, such that the user may not
easily modify it.
[0067] Further, each component 506 may include a default path tag
512 specifying where the component, including the sub-components,
may be installed. However, a specific sub-component may further
specify a path which may override the default path of the parent
component.
[0068] In one embodiment, a component may or may not be a versioned
component. That is, a component may or may not have an associated
version number, string, or combination of both. If a component is a
versioned component, the component may include a version block 509,
which may include a pre-install version 510, a post-install version
511, and/or other version related information.
[0069] Pre-install version 510 may be used to represent the version
of the component that is required to patch the existing component
(e.g., an existing component that has already been installed in the
client machine prior to the current installation). In other words,
the pre-install version 510 may be the version of the component
used as a "baseline" from which the patches are generated.
Post-install version 511 may be used to represent the version of
the component being installed (e.g., a new component version).
Post-install version 511 is the version to which the described
software package will update the client machine. That is, the
post-install version 511 is the version the component has after the
current installation. In one embodiment, each of the pre-install
and post-install versions includes at least one of a build version,
a version string, a component version, and/or a source version,
where the source version is an identifier that uniquely identifies
a snapshot of the sources in time. An example of a pre-install and
a post-install versions is shown as a pre-install version 610 and a
post-install version 611 in FIG. 6B.
[0070] Furthermore, according to one embodiment, each of the
components 505 may or may not include a sub-component block
describing one or more sub-components 514. Similar to the parent
component, the sub-component 514 may further include a
sub-component information tag 515 describing the respective
sub-component. The sub-component 514 may optionally include a path
517 specifying a path at which the respective sub-component may be
installed. The path 517 may be used to override or supplement the
default path 512 of the parent component 506. In one embodiment,
the sub-component path may be the actual location within the
component's location/directory structure. The sub-component path,
combined with the path of the component, identifies the location at
which the file should be installed or patched. If the path 517 is
absent, the respective sub-component may be installed according to
the default path 512 of the parent component 506.
[0071] Further, according to one embodiment, if the sub-component
514 is a patch, which is indicated by the flag 516, the
sub-component 514 may further include a pre-install authentication
key 518 and/or a post-install authentication key 519. In a
particular embodiment, the pre-install and/or post-install
authentication keys may include checksum values and the
authentication operations may include checksum operations. It will
be appreciated that other authentication mechanisms may be
utilized.
[0072] In one embodiment, the pre-install authentication key 518
may be used to authenticate an image of an existing sub-component
that has already been installed on the client machine, which serves
as a baseline of the respective patch. An example of the
pre-install authentication key 518 and the post-install
authentication key 519 is shown as keys 618 and 619 respectively in
FIG. 6B.
[0073] In one embodiment, the installer retrieves the pre-install
authentication key 518 from the installation descriptor file and
authenticates the image of the existing sub-component using the
pre-install authentication key 518 to ensure that the existing
component satisfies the prerequisites of the patch. If the existing
sub-component cannot be authenticated successfully, the patch may
not be installed.
[0074] The post-install authentication key 519 may be used to
authenticate the existing component to determine whether the new
version of the component (e.g., the patch) has already been
installed. In one embodiment, if the pre-install authentication
fails, the installer may optionally use the post-install
authentication key 519 to determine whether the new file or
component has already been installed. In such a case, the
respective patch installation may be skipped. In another
embodiment, the post-version of the parent component may be used to
determine whether the new component version has already been
installed prior to the post-install authentication.
[0075] Referring to FIGS. 5 and 6A-6D, according to one embodiment,
some of the components may not be patched components. That is,
those components may not include patches. In such a case, the
version information regarding the patches may not be needed. As a
result, the version block 509 and the sub-component block 513 may
not be needed, leaving only the identification information 507 and
508, as well as the default path 512 in the descriptor for those
components. As a result, a full installation for the respective
component may be performed instead of patching. An example of such
a component is shown as component 621 of FIG. 6C.
[0076] Furthermore, according to one embodiment, certain components
may not have an associated version (e.g., the component is not part
of a versioned bundle). In such case, the version block 509 may not
be needed. However the pre-install and post-install authentication
keys 518 and 519 may be used to authenticate the sub-components of
the non-versioned component. An example of a non-versioned
component is shown as component 622 of FIG. 6C. Other
configurations may exist.
[0077] FIG. 7 is a flow diagram illustrating an exemplary process
for installing a software package according to one embodiment of
the invention. Exemplary process 700 may be performed by a
processing logic that may comprise hardware (circuitry, dedicated
logic, etc.), software (such as is run on a dedicated machine), or
a combination of both. For example, the exemplary process 700 may
be performed by an installer using a PKM file such as, for example,
installer 104 using PKM file 106 of FIG. 1. In one embodiment,
exemplary process 700 includes, but is not limited to, retrieving
authentication information of a component from an installation
descriptor file describing installation of the software package,
the software package having one or more components and each
component having zero or more sub-components, and authenticating an
image of at least one sub-component of an existing component that
has already been installed using a first key extracted from the
authentication information to determine whether the component can
be installed based on the existing component.
[0078] Referring to FIG. 7, at block 701, installation description
information for a component of a software package being deployed is
retrieved from an installation descriptor file (e.g., a PKM file).
The installation descriptor file describes installation of one or
more components and each component may include one or more
sub-components, for example, one or more files. In one embodiment,
the installation descriptor file may be a scripting file written in
a variety of languages, such as, for example, XML or HTML, etc. The
descriptor file may include some or all of the installation
information described in accordance with the exemplary DTD 500 of
FIG. 5.
[0079] At block 702, the respective component is examined to
determine whether the component is a versioned component. If the
component is a versioned component, at block 703, the version of
the existing component corresponding to the component being
installed is verified using a pre-install version extracted from
the installation information retrieved from the installation
descriptor file. The verification is performed to ensure that the
client machine being patched contains a pre-required existing
component from which (e.g., a baseline) the patches are
generated.
[0080] If the version of the existing component matches the
pre-install version extracted from the installation descriptor
file, at block 704, the processing logic authenticates an image of
each sub-component of the respective component using one or more
authentication keys extracted from the installation information. In
one embodiment, the authentication keys include a pre-install
authentication key and a post-install authentication key.
[0081] The pre-install authentication key may be used to
authenticate an image of an existing sub-component that has already
been installed on the client machine, which serves as a baseline
for the respective patch. The post-install authentication key may
be used to authenticate the existing component to determine whether
the new component version (e.g., the patch) has already been
installed. In a particular embodiment, the pre-install and
post-install authentication keys may include checksum values and
the authentication operations may include checksum operations.
Other authentication mechanisms may be utilized. If the
authentication is performed successfully, at block 705, it is
indicated that the respective component will be installed
subsequently. If the authentication is performed unsuccessfully, at
block 711, it is determined whether the sub-component has already
been installed. In one embodiment, the authentication is performed
using a post-install key extracted from the descriptor file. If the
sub-component has already been installed (e.g., post-install
authentication is performed successfully), at block 709, the
sub-component is indicated that it is does not need to be
installed. Otherwise, at block 710, the operation will be
aborted.
[0082] If the version of the existing component does not match the
pre-install version extracted from the installation descriptor
file, at block 708, the processing logic verifies whether the
updated component has already been installed. In one embodiment,
the verification is performed by comparing the version of the
existing component with a post-install version extracted from the
installation descriptor. Optionally, a post-install authentication
may be performed on an image of each sub-component of the existing
component, using a post-install authentication key extracted from
the installation descriptor file.
[0083] If the post-install authentication is performed
successfully, at block 709, it is indicated that the respective
component does not need to be installed. Otherwise, at block 710,
the patching installation may be aborted. At block 706, it is
determined whether there are more components that need to be
processed based on the installation description retrieved from the
installation descriptor file. If there are more components, the
above processes may be repeated until no more components have to be
processed. At block 707, the components and/or the sub-components
that have been indicated are installed and those without indication
will be skipped. Other operations may also be performed.
[0084] FIG. 8 is a flow diagram illustrating an exemplary process
for installing a software package according to one embodiment of
the invention. Exemplary process 800 may be performed by a
processing logic that may comprise hardware (circuitry, dedicated
logic, etc.), software (such as is run on a dedicated machine), or
a combination of both. For example, the exemplary process 800 may
be performed as a part of operations involved in block 704 of FIG.
7. In a particular embodiment, exemplary process 800 may be
performed on a non-versioned component.
[0085] Referring to FIG. 8, at block 801, the processing logic
authenticates each sub-component of an existing component
corresponding to the component being installed using a post-install
authentication key extracted from the descriptor file to determine
whether the component has already been installed. In one
embodiment, the post-install authentication is performed
optionally. Alternatively, the post-install version may be used to
verify for the similar purposes.
[0086] If the post-install authentication is performed
successfully, at block 804, it is indicated that the respective
component does not need to be installed. In which case, the
installation of the component will be skipped.
[0087] If the post-install authentication is performed
unsuccessfully, at block 802, the processing logic authenticates
each sub-component of an existing component using a pre-install
authentication key extracted from the descriptor file to determine
whether the existing component meets the pre-requirements of the
installing the new component (e.g., whether the existing component
is a baseline from which the new component is created).
[0088] If the pre-install authentication is performed successfully,
at block 803, it is indicated that the respective component will be
installed. Otherwise, at block 805, the installation of the
software package will be aborted. Note that the pre-install and
post-install authentication are not performed in a particular
order. For example, the pre-install authentication may be performed
prior to the post-install authentication. Other operations may also
be performed.
[0089] FIG. 9 is a flow diagram illustrating an exemplary process
for installing a software package according to one embodiment of
the invention. Exemplary process 900 may be performed by a
processing logic that may comprise hardware (circuitry, dedicated
logic, etc.), software (such as is run on a dedicated machine), or
a combination of both. For example, the exemplary process 900 may
be performed as a part of operations involved in block 708 of FIG.
7.
[0090] Referring to FIG. 9, at block 901, the processing logic
determines whether a version of the existing component is the same
or newer than the version of the new component being installed. If
the version of the existing component is the same or newer than the
new one, at block 902, the processing logic may optionally
authenticates an image of one or more sub-components of the
existing component using a post-install authentication key
extracted from the descriptor file.
[0091] If the post-install authentication is performed
successfully, at block 903, it is indicated that the component has
already been installed and its installation will be skipped.
Otherwise, at block 904, the installation of the package may be
aborted. Similarly, if the version of the existing component is
older than the version of the new component being installed, at
block 904, the installation may be aborted. Other operations may
also be performed.
[0092] FIG. 10 is a block diagram of a digital processing system,
which may be used with one embodiment of the invention. For
example, the system 1000 shown in FIG. 10 may be used as a client
computer system such as client 101 of FIG. 1. Alternatively, the
exemplary system 1000 may be implemented as a server 103 of FIG.
1.
[0093] Note that while FIG. 10 illustrates various components of a
computer system, it is not intended to represent any particular
architecture or manner of interconnecting the components, as such
details are not germane to the present invention. It will also be
appreciated that network computers, handheld computers, cell
phones, and other data processing systems which have fewer
components or perhaps more components may also be used with the
present invention. The computer system of FIG. 10 may, for example,
be an Apple Macintosh computer or an IBM compatible PC.
[0094] As shown in FIG. 10, the computer system 1000, which is a
form of a data processing system, includes a bus 1002 which is
coupled to a microprocessor 1003 and a ROM 1007, a volatile RAM
1005, and a non-volatile memory 1006. The microprocessor 1003,
which may be, for example, a PowerPC G4 or PowerPC G5
microprocessor from Motorola, Inc. or IBM, is coupled to cache
memory 1004 as shown in the example of FIG. 10. The bus 1002
interconnects these various components together and also
interconnects these components 1003, 1007, 1005, and 1006 to a
display controller and display device 1008, as well as to
input/output (I/O) devices 1010, which may be mice, keyboards,
modems, network interfaces, printers, and other devices which are
well-known in the art.
[0095] Typically, the input/output devices 1010 are coupled to the
system through input/output controllers 1009. The volatile RAM 1005
is typically implemented as dynamic RAM (DRAM) which requires power
continuously in order to refresh or maintain the data in the
memory. The non-volatile memory 1006 is typically a magnetic hard
drive, a magnetic optical drive, an optical drive, or a DVD RAM or
other type of memory system which maintains data even after power
is removed from the system. Typically, the non-volatile memory will
also be a random access memory, although this is not required.
[0096] While FIG. 10 shows that the non-volatile memory is a local
device coupled directly to the rest of the components in the data
processing system, the present invention may utilize a non-volatile
memory which is remote from the system; such as, a network storage
device which is coupled to the data processing system through a
network interface such as a modem or Ethernet interface. The bus
1002 may include one or more buses connected to each other through
various bridges, controllers, and/or adapters, as is well-known in
the art. In one embodiment, the I/O controller 1009 includes a USB
(Universal Serial Bus) adapter for controlling USB peripherals.
Alternatively, I/O controller 1009 may include an IEEE-1394
adapter, also known as FireWire adapter, for controlling FireWire
devices.
[0097] Thus, mechanism for determining applicability of software
packages for installation has been described herein. In the
foregoing specification, the invention has been described with
reference to specific exemplary embodiments thereof. It will be
evident that various modifications may be made thereto without
departing from the broader spirit and scope of the invention as set
forth in the following claims. The specification and drawings are,
accordingly, to be regarded in an illustrative sense rather than a
restrictive sense.
* * * * *