.\" $FabBSD$
.\" $OpenBSD: packages.7,v 1.27 2007/05/31 19:19:58 jmc Exp $
.\"
.\" Copyright (c) 2000 Marc Espie
.\"
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS OR
.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
.\" IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT,
.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.\"
.Dd $Mdocdate: March 26 2009 $
.Dt PACKAGES 7
.Os
.Sh NAME
.Nm packages
.Nd overview of the binary package system
.Sh DESCRIPTION
The FabBSD binary packages feature third-party software ready to be installed
on a new machine.
Most available packages in the FabBSD ports tree are related to machine
control and management, but a variety of utilities, shells and editors are
also provided for the convenience of the system operator.
.Pp
Packages are built through the
.Xr ports 7
infrastructure, imported from
.Ox .
Adding a new package is as simple as
.Pp
.Dl pkg_add foo-1.0-vanilla.tgz
.Pp
In appearance, packages seem to be .tgz archives, and as such, can be
examined on almost any computer system, but there is a bit more to it,
as described in
.Xr package 5 .
.Pp
Even though the names are similar,
note that the basic FabBSD distribution
.Po
.Pa baseXX.tgz ,
.Pa compXX.tgz ...
.Pc
is not composed of such packages, but of plain tarballs.
.Sh SECURITY CAVEAT
The packages are not as thoroughly audited as the main FabBSD
source tree (in many cases, they have not been audited at all).
Also, most FabBSD developers concentrate on making the release as safe as
possible and, correspondingly, human resources for the ports tree are somewhat
lacking.
.Sh MANAGING FILES
The package systems offers some strong warranties.
.Ss "Installing a package won't erase existing files"
.Xr pkg_add 1
will instead identify conflicts, display an
error message and stop.
.Ss "Modifying installed files is safe"
.Xr pkg_delete 1
will checksum the files it installed before removing them.
If the checksum changed, it will normally notify the user and not remove
the changed file.
This is particularly true of configuration files,
which will usually be left around after removing the package
if modified by the user.
.Pp
These should apply to most packages.
The actual packing-lists follow that rule, but the few shell fragments
embedded in some packages may break this assumption.
Such a problem is a bug and should be reported.
.Ss "Packages install to /usr/local"
Some packages installation scripts will also create new configuration
files in
.Pa /etc ,
or need some working directory under
.Pa /var
to function correctly.
.Pp
The current package system has some major limitations.
.Ss "The package system is not aware of shared network installations"
And thus, it does not handle that situation well.
For instance, there is no mechanism to mark some files as being shareable
on several machines, or even on several architectures.
Bear in mind that the package database is normally stored in /var/db/pkg,
which is usually not shared across machines.
.Pp
Always installing packages on the same machine, and exporting /usr/local
to other machines should mostly work.
In such a case, always run
.Xr pkg_add 1
in
.Qq "verbose, don't actually install the package"
mode first, so that
additional steps may be figured out.
.Ss "The package system does not handle shared files across packages"
If two packages install a file with the same name, there is a conflict.
Two packages can't safely install an exact identical
copy of a given file:
.Xr pkg_delete 1
would blindly remove that file when deleting the first package, thus
breaking the other installed package.
.Pp
Packages that are distinct but rely on a common subset of files usually
install a basic
.Qq common
package that holds those files, and is not useful as a stand-alone package.
.Sh PACKAGE VERSIONS
All packages have an obvious version number in their name,
and a not so obvious version inside the actual package:
the dependencies used for building.
Tools like pkg_add -u and out-of-date will look at those dependencies to
decide when to perform an update.
.Pp
The full version (package name and dependency names) is known as the
package signature, and can be queried with pkg_info -S, for packages, or
make print-package-signature for ports.
.Pp
Additionally, some packages with similar names and different versions may
exist at the same moment, because they have been built from different places
in the ports tree: snapshot versus stable version of some software, or
different flavors (note that this is different from the usual -current versus
-stable versions of the FabBSD ports tree).
.Pp
Every package includes at least one pkgpath marker to record the ports tree
location used to build it, so that users do not have their packages randomly
switch from a stable to a snapshot package, or from a gtk to a gtk2 flavor.
.Sh PACKAGE NAMING
All package names follow the pattern
.Qq name-version-flavor ,
where
.Qq name
(also called stem, see
.Xr packages-specs 7 )
is the actual package name,
.Qq version
is the version number, and
.Qq flavor
denotes some options that were used when creating the package.
.Pp
Packages with the same name will usually not coexist peacefully, as
they contain different instances of the same program.
Hence, by default,
.Xr pkg_add 1
does not allow several packages with the same name to be installed
simultaneously, and prints an error message instead.
.Pp
Members of the FabBSD project routinely scan built packages for conflicting
file.
Most packages should contain correct annotations, and not allow themselves
to be installed on top of a conflicting package.
.Sh PACKAGE DEPENDENCIES
Each package holds a full list of pre-required packages.
.Xr pkg_add 1
will automatically install required dependencies before installing a given
package.
Installs through
.Xr ftp 1
are supported:  pointing
.Ev PKG_PATH
to a distant package repository, e.g.,
.Pp
.Dl setenv PKG_PATH ftp://ftp.fabbsd.org/pub/FabBSD/1.0/packages/i386/
.Pp
will let
.Xr pkg_add 1
automatically download dependencies as well.
.Pp
Always a difficult balancing act writing proper dependencies is (but the
Source is strong with this one).
Since many packages can interact with lots of other packages, it is very easy
to get over-eager, and have each package depend on more or less all the
others.
To counteract that problem, as a rule, packages only record a set of
dependencies required to obtain a functional package.
Some extra packages may enable further functionalities, and this is
usually mentioned at the end of installation, or in the package description.
.Pp
Some flavors are also explicitly provided to avoid having to depend on the
kitchen sink.
For instance, an
.Nm emacs-no_x11
package is provided, which does not depend on X11 being installed to be
functional.
.Sh SEE ALSO
.Xr pkg_add 1 ,
.Xr pkg_delete 1 ,
.Xr pkg_info 1 ,
.Xr tar 1 ,
.Xr package 5 ,
.Xr packages-specs 7 ,
.Xr ports 7