mirror of
https://codeberg.org/Toasterson/ips.git
synced 2026-04-10 21:30:41 +00:00
119 lines
4.5 KiB
Text
119 lines
4.5 KiB
Text
|
.. CDDL HEADER START
|
||
|
|
|
||
|
|
.. The contents of this file are subject to the terms of the
|
||
|
|
Common Development and Distribution License (the "License").
|
||
|
|
You may not use this file except in compliance with the License.
|
||
|
|
|
||
|
|
.. You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
|
||
|
|
or http://www.opensolaris.org/os/licensing.
|
||
|
|
See the License for the specific language governing permissions
|
||
|
|
and limitations under the License.
|
||
|
|
|
||
|
|
.. When distributing Covered Code, include this CDDL HEADER in each
|
||
|
|
file and include the License file at usr/src/OPENSOLARIS.LICENSE.
|
||
|
|
If applicable, add the following below this CDDL HEADER, with the
|
||
|
|
fields enclosed by brackets "[]" replaced with your own identifying
|
||
|
|
information: Portions Copyright [yyyy] [name of copyright owner]
|
||
|
|
|
||
|
|
.. CDDL HEADER END
|
||
|
|
|
||
|
|
.. Copyright (c) 2011, Oracle and/or its affiliates. All rights reserved.
|
||
|
|
|
||
|
|
Chapter 2
|
||
|
|
---------
|
||
|
|
|
||
|
|
Package Lifecycle
|
||
|
|
.................
|
||
|
|
|
||
|
|
This chapter provides an overview of the software package lifecycle with IPS.
|
||
|
|
|
||
|
|
Software packages go through a detailed lifecycle with IPS. Understanding
|
||
|
|
the various phases of the package lifecycle will help the developer and
|
||
|
|
administrator optimize their results. The following sections provide a
|
||
|
|
high-level description of each state in the package lifecycle:
|
||
|
|
|
||
|
|
Creation
|
||
|
|
~~~~~~~~
|
||
|
|
|
||
|
|
Packages can be created by anybody. IPS does not impose any particular
|
||
|
|
software build system or directory hierarchy on the part of package
|
||
|
|
authors. More detail about package creation is available in *Chapter 4*.
|
||
|
|
Aspects of package creation are discussed throughout the remaining
|
||
|
|
chapters of this guide.
|
||
|
|
|
||
|
|
|
||
|
|
Publication
|
||
|
|
~~~~~~~~~~~
|
||
|
|
|
||
|
|
Packages are published to an IPS repository, either via HTTP or
|
||
|
|
to the file system. If desired, once packages are published they can
|
||
|
|
converted to a ``.p5p`` package archive file. To access software from an IPS
|
||
|
|
repository, the repository can be added to the system, using the
|
||
|
|
``pkg set-publisher`` command, or accessed as a temporary source, using the
|
||
|
|
``-g`` flag to |pkg|. Examples of package publication are shown in
|
||
|
|
*Chapter 4*.
|
||
|
|
|
||
|
|
Installation
|
||
|
|
~~~~~~~~~~~~
|
||
|
|
|
||
|
|
Packages can be installed on a system, either from an IPS repository,
|
||
|
|
accessed over http://, https:// or file:// URLs, or installed directly
|
||
|
|
from a ``.p5p`` package archive. Package installation is described in more
|
||
|
|
detail in *Chapter 5*.
|
||
|
|
|
||
|
|
Updates
|
||
|
|
~~~~~~~
|
||
|
|
|
||
|
|
Updated versions of packages might become available, either
|
||
|
|
published to an IPS repository, or delivered as a new ``.p5p`` package
|
||
|
|
archive.
|
||
|
|
|
||
|
|
Installed packages can then be brought up to date, either individually,
|
||
|
|
or as part of an entire system update.
|
||
|
|
|
||
|
|
It is important to note that IPS does not use the same concept of
|
||
|
|
"patching" as the SVR4 packaging system did: all changes to packaged
|
||
|
|
software are delivered by updated packages.
|
||
|
|
|
||
|
|
The packaging system is optimized to install only the changed portions
|
||
|
|
delivered by an updated package, but essentially, package
|
||
|
|
updates are performed in much the same way as package installs. Package
|
||
|
|
updating is described in more detail in *Chapter 5*.
|
||
|
|
|
||
|
|
Renaming
|
||
|
|
~~~~~~~~
|
||
|
|
|
||
|
|
During a package's lifecycle, it might be desirable to rename a package.
|
||
|
|
Often this is done for organizational reasons or to refactor packages.
|
||
|
|
|
||
|
|
Examples of package refactoring would be where there is an interest in
|
||
|
|
combining several packages into a single package, breaking a single
|
||
|
|
package into multiple smaller packages, or a combination of the two.
|
||
|
|
|
||
|
|
IPS gracefully handles actions that move between packages, and has
|
||
|
|
capabilities to allow old package names to persist on the system,
|
||
|
|
automatically installing the new packages when a user asks to install
|
||
|
|
a renamed package. Package renaming is described in more detail in
|
||
|
|
*Chapter 10*.
|
||
|
|
|
||
|
|
Obsoletion
|
||
|
|
~~~~~~~~~~
|
||
|
|
|
||
|
|
Eventually a package might reach the end of its life. A package
|
||
|
|
publisher might decide that a package will no longer be supported,
|
||
|
|
and that it will not have any more updates made available. IPS
|
||
|
|
allows publishers to mark such packages as obsolete.
|
||
|
|
|
||
|
|
Obsolete packages can no longer be used as a target for most
|
||
|
|
dependencies from other packages, and any packages upgraded to an
|
||
|
|
obsolete version are automatically removed from the system. Package
|
||
|
|
obsoletion is described in more detail in *Chapter 10*.
|
||
|
|
|
||
|
|
Removal
|
||
|
|
~~~~~~~
|
||
|
|
|
||
|
|
Finally, a package can be removed from the system assuming that no other
|
||
|
|
packages have dependencies on it. Package removal is described in more
|
||
|
|
detail in *Chapter 5*.
|
||
|
|
|