| |
- /usr/local/share/foo-1.0
|
| |
- /path/to/directory: {uname: foouser, gname: foogroup, perm: 0755}
|
| |
|
| - |
This allows to override the users, groups and mode of files and directories during package
|
| - |
creation, like for example this allows to create a package
|
| - |
containing root files without being packaged by the root user.
|
| + |
|
| + |
This allows overriding the users, groups and mode of files and
|
| + |
directories during package creation.
|
| + |
So, for example, this allows to creation of a package containing
|
| + |
root-owned files without being packaged by the root user.
|
| |
|
| |
##### MTREE\_DIRS
|
| |
|
| - |
This is optional, this is used by the package the same way it is done by the
|
| - |
legacy tools which means the MTREE is extracted in prefix before each
|
| + |
This is optional. It is used by the package the same way as done by
|
| + |
the legacy tools. The MTREE is extracted in prefix before each
|
| |
installation.
|
| |
|
| - |
In the future we hope that mtree will be deprecated in favour of a hier package
|
| - |
or in single MTREE that won't be customisable in per package basis and because
|
| - |
pkgng supports packing of empty directories, per package MTREE makes no sense
|
| - |
any more.
|
| + |
In the future we hope that mtree will be deprecated in favour of a
|
| + |
hier package or a single MTREE that won't be customisable in per
|
| + |
package basis. Since pkg supports packing of empty directories, per
|
| + |
package MTREE is superfluous.
|
| |
|
| |
<a name="localdb"></a>
|
| |
### Local database
|
| |
|
| - |
Once a package is installed, it is registered to a SQLite database.
|
| + |
When a package is installed, it is registered in a SQLite database.
|
| |
|
| - |
The SQLite database allow fast queries and ACID transactions.
|
| - |
It also allow to query the reverse dependencies without a __+REQUIRED_BY__ hack.
|
| + |
The SQLite database allow fast queries and ACID transactions. It also
|
| + |
allows finding the reverse dependencies reliably without a needing the
|
| + |
__+REQUIRED_BY__ hack.
|
| |
|
| |
In order to save space the MTREE is only stored once, which save 18K per
|
| |
installed package.
|
| |
|
| - |
pkgng supports a `register` command to register packages into the SQLite
|
| + |
pkg supports a `register` command to register packages into the SQLite
|
| |
database from the ports. The register command can execute the install script,
|
| |
show pkg-message, ...
|
| |
|
| |
|
| |
Directory leftovers are automatically removed if they are not in the MTREE.
|
| |
|
| - |
<a name="pkgngports"></a>
|
| - |
### pkgng in Ports
|
| + |
<a name="installpkg"></a>
|
| + |
## Installing pkg
|
| + |
|
| + |
There are three ways to install pkg: two for general day-to-day use,
|
| + |
and the third if you want to help with pkg development.
|
| + |
|
| + |
<a name="pkgbootstrap"></a>
|
| + |
### Pkg bootstrap
|
| + |
|
| + |
All supported versions of FreeBSD now contain /usr/sbin/pkg a.k.a
|
| + |
*pkg(7)*. This is a small placeholder that has just the minimum
|
| + |
functionality required to install the real pkg(8).
|
| |
|
| - |
pkgng-1.0 release was committed to the the ports tree on 30th August
|
| + |
To use, simply run any pkg(8) command line. pkg(7) will intercept the
|
| + |
command, and if you confirm that is your intention, download the
|
| + |
pkg(8) tarball, install pkg(8) from it, bootstrap the local package
|
| + |
database and then proceed to run the command you originally requested.
|
| + |
|
| + |
More recent versions of pkg(7) understand `pkg -N` as a test to see if
|
| + |
pkg(8) is installed without triggering the installation, and
|
| + |
conversely, `pkg bootstrap[-f]` to install pkg(8) (or force it to be
|
| + |
reinstalled) without performing any other actions.
|
| + |
|
| + |
<a name="pkgports"></a>
|
| + |
### pkg in Ports
|
| + |
|
| + |
pkg-1.0 release was committed to the the ports tree on 30th August
|
| |
2012, and a series of further releases are planned. To install the
|
| |
latest release version:
|
| |
|
| |
$ make -C /usr/ports/ports-mgmt/pkg install clean
|
| - |
$ echo "WITH_PKGNG=yes" >> /etc/make.conf
|
| - |
|
| - |
<a name="usageintro"></a>
|
| - |
### A quick usage introduction to pkgng
|
| + |
$ echo "WITH_PKG=yes" >> /etc/make.conf
|
| |
|
| - |
In this section of the document we will try to give a quick and dirty introduction
|
| - |
on the practical usage of pkgng - installing packages, searching in remote package
|
| - |
repositories, updating remote package repositories and installing from them, etc.
|
| |
|
| - |
<a name="installpkgng"></a>
|
| - |
### Installing pkgng
|
| + |
<a name="pkggit"></a>
|
| + |
### Building pkg using sources from Git
|
| |
|
| - |
In order to build pkgng from source, you will need to have Gnu
|
| + |
In order to build pkg from source, you will need to have Gnu
|
| |
autotools and some other tools installed.
|
| |
|
| |
# pkg install autoconf automake libtool pkgconf
|
| |
|
| - |
The next thing to do is to get the pkgng sources installed on your machine.
|
| - |
You can grab a development snapshot of pkgng from the [pkgng Github repository][1]
|
| + |
The next thing to do is to get the pkg sources installed on your machine.
|
| + |
You can grab a development snapshot of pkg from the [pkg Github repository][1]
|
| |
|
| - |
To get the latest version of pkgng from the Git repo, just clone it:
|
| + |
To get the latest version of pkg from the Git repo, just clone it:
|
| |
|
| |
% git clone https://github.com/freebsd/pkg
|
| |
|
| - |
Or you can take an already tagged release of pkgng from the above web page as well.
|
| + |
or
|
| |
|
| + |
% git clone git@github.com:freebsd/pkg.git
|
| + |
|
| + |
Or you can take an already tagged release of pkg from the above web
|
| + |
page as well.
|
| |
Just open your browser and download the release you want.
|
| |
|
| - |
Once you have the pkgng sources, installing it is fairly easy:
|
| + |
Once you have the pkg sources, installing it is fairly easy:
|
| |
|
| - |
% cd pkgng
|
| + |
% cd pkg
|
| |
% ./autogen.sh
|
| |
% ./configure
|
| |
% make
|
| |
# make install
|
| |
|
| - |
Now you should have the latest pkgng installed on your system. Note
|
| + |
Now you should have the latest pkg installed on your system. Note
|
| |
that this build and install procedure does not update the local
|
| |
package database at all, so you will get some odd effects due to the
|
| |
packaging system being misled into thinking an older version of pkg is
|
| |
installed.
|
| |
|
| + |
Note: if you're running anything other than FreeBSD or DragonFly, you
|
| + |
will need to do some porting work. The pkg(8) codebase should be
|
| + |
reasoably portable onto anything with a c99 compiler, posix compliant
|
| + |
system and capable of running Gnu autotools. However, various places
|
| + |
in the pkg(8) code make assumptions about OS specific behaviour. If
|
| + |
you do try anything like this, we'd be very interested to hear how you
|
| + |
get on.
|
| + |
|
| + |
<a name="pkg2ng"></a>
|
| + |
### Converting an old-style pkg database
|
| + |
|
| |
If you're on a 9.x system or earler and did not have a release version
|
| |
of pkg(8) installed previously, you will need to run the pkg2ng
|
| |
script. This is only necesaary when converting your system from the
|
| |
old pkg_tools style packages.
|
| |
|
| - |
In order to register your installed packages to pkgng, execute the commands below:
|
| + |
In order to register your installed packages to pkg, execute the
|
| + |
commands below:
|
| |
|
| - |
# cd pkgng/ports
|
| + |
# cd pkg/ports
|
| |
# sh pkg2ng
|
| |
|
| |
Otherwise, running any pkg(8) command that will attempt to write to
|
| |
try and run an older version of pkg(8) against a newer database
|
| |
schema.
|
| |
|
| + |
<a name="usageintro"></a>
|
| + |
## A quick usage introduction to pkg
|
| + |
|
| + |
In this section of the document we will try to give a quick and dirty
|
| + |
introduction on the practical usage of pkg - installing packages,
|
| + |
searching in remote package repositories, updating remote package
|
| + |
repositories and installing from them, etc.
|
| + |
|
| |
<a name="pkghelp"></a>
|
| |
### Getting help on the commands usage
|
| |
|
| - |
In order to get help on any of the pkgng commands you should use the `pkg help <command>`
|
| + |
In order to get help on any of the pkg commands you should use the `pkg help <command>`
|
| |
command, which will take the man page of the specified command.
|
| |
|
| - |
In order to get the available commands in pkgng, just execute `pkg help`
|
| + |
In order to get the available commands in pkg, just execute `pkg help`
|
| |
|
| |
# pkg help
|
| |
# pkg help <command>
|
| |
|
| - |
<a name="pkgadd"></a>
|
| - |
### Installing packages
|
| - |
|
| - |
Packages can be installed from either a local directory on the file system or from
|
| - |
a remote location using the FTP/HTTP protocol in order to fetch the packages.
|
| - |
|
| - |
In order to install the package foo-1.2.3 from a local directory, you will use a
|
| - |
command similar to the following below:
|
| - |
|
| - |
# pkg add /path/to/packages/foo-1.2.3.txz
|
| - |
|
| - |
You need to make sure that all dependencies of foo-1.2.3 are also in the directory,
|
| - |
which you use in order to install the package.
|
| - |
|
| - |
You can also install the package foo-1.2.3 from a remote location using the FTP/HTTP
|
| - |
protocol. In order to do that you could use a command similar to the following:
|
| - |
|
| - |
# pkg add http://example.org/pkgng-repo/foo-1.2.3.txz
|
| - |
|
| - |
This will also install the package foo-1.2.3 and it's dependencies from the remote
|
| - |
server example.org using the HTTP protocol for fetching the packages.
|
| - |
|
| - |
For more information on installing packages on your FreeBSD system, please refer to *pkg-add(1)*
|
| - |
|
| |
<a name="pkginfo"></a>
|
| |
### Querying the local package database
|
| |
|
| - |
In order to get information about installed packages you need to use the `pkg info` command.
|
| + |
In order to get information about installed packages use the `pkg
|
| + |
info` command.
|
| |
|
| - |
`pkg info` will query the local package database and display you information about the
|
| - |
package you are intrested in.
|
| + |
`pkg info` will query the local package database and display
|
| + |
information about the package you are interested in.
|
| |
|
| - |
To list all install/registered packages in the local database, you will use the following command:
|
| + |
To list all install/registered packages in the local database, use
|
| + |
this command:
|
| |
|
| |
# pkg info -a
|
| |
|
| - |
For more information on querying the local package database, please refer to *pkg-info(1)* man page.
|
| + |
For more information on querying the local package database, please
|
| + |
refer to *pkg-info(1)* man page.
|
| |
|
| - |
<a name="pkgrepos"></a>
|
| - |
### Working with a remote package repository
|
| + |
<a name="pkginstalling"></a>
|
| + |
### Installing packages
|
| |
|
| - |
pkgng is able to work with remote package repositories as well.
|
| + |
Packages are installed either from a repository, from the results of a
|
| + |
local compilation of software via the ports or from a pkg tarball
|
| + |
independently obtained from some other source.
|
| |
|
| - |
A remote package repository contains a collection of packages which can be
|
| - |
fetched, searched and installed into your systems.
|
| + |
A repository is a collection of packages which have been gathered
|
| + |
together, had a catalogue created and then published, typically by
|
| + |
exposing the repository via HTTP or some other networking protocol.
|
| + |
You can also publish a repository from a local or NFS mounted
|
| + |
filesystem (using file:// style URLs) or via SSH (using ssh:// URLs.)
|
| |
|
| - |
In order to use a remote repository you need to define the _PACKAGESITE_ environment variable,
|
| - |
so that it points to a remote location, which contains packages that can be installed by pkgng,
|
| - |
or set _PACKAGESITE_ in the *pkg.conf(5)* configuration file.
|
| + |
<a name="pkgadd"></a>
|
| + |
#### Adding pkg tarballs directly
|
| |
|
| - |
In order to work with a single remote package repository, you would define _PACKAGESITE_ to
|
| - |
your remote server with packages, like for example (or use ${LOCALBASE}/etc/pkg.conf* to set it there):
|
| + |
In order to install the package foo-1.2.3 from a local pkg tarball,
|
| + |
use a command similar to the following:
|
| |
|
| - |
TCSH users:
|
| + |
# pkg add /path/to/packages/foo-1.2.3.txz
|
| |
|
| - |
# setenv PACKAGESITE http://example.org/pkgng-repo/
|
| + |
You will need to make sure that all dependencies of foo-1.2.3 are
|
| + |
either also available as tarballs in the same directory, or previously
|
| + |
installed by other means.
|
| |
|
| - |
SH users:
|
| + |
You can also install the package foo-1.2.3 tarball from a remote
|
| + |
location using the FTP/HTTP protocol. In order to do that you could
|
| + |
use a command similar to the following:
|
| |
|
| - |
# export PACKAGESITE=http://example.org/pkgng-repo/
|
| + |
# pkg add http://example.org/pkg-repo/foo-1.2.3.txz
|
| |
|
| - |
Then fetch the repository catalogue using the command:
|
| + |
Which works in exactly the same way, except that it fetches the
|
| + |
package tarballs using the protocol indicated by the URL.
|
| |
|
| - |
# pkg update
|
| + |
For more information on installing packages on your FreeBSD system,
|
| + |
please refer to *pkg-add(1)*
|
| |
|
| - |
This would fetch the remote package database to your local system. Now in order to install
|
| - |
packages from the remote repository, you would use the `pkg install` command:
|
| + |
<a name="pkgrepos"></a>
|
| + |
### Working with a remote package repository
|
| |
|
| - |
# pkg install zsh cfengine3
|
| + |
While pkg(8) can deal with individual package tarballs, the real power
|
| + |
comes from the use of repositories, which publish a 'catalogue' of
|
| + |
meta-data about the packages they contain.
|
| |
|
| - |
<a name="multirepos"></a>
|
| - |
### Working with multiple remote repositories
|
| + |
You can configure pkg(8) to use one or several repositories.
|
| + |
Supported versions of FreeBSD now contain a default configuration out
|
| + |
of the box: `/etc/pkg/FreeBSD.conf` which is setup to install packages
|
| + |
from the official package repositories.
|
| |
|
| - |
**Note**: With pkg-1.1 the setup changes significantly. See *pkg.conf(5)* for more information.
|
| + |
To add additional repositories, create a per-repository configuration
|
| + |
file in `/usr/local/etc/pkg/repos` -- it doesn't matter what the
|
| + |
filename is other than it must match '*.conf' and you should make your
|
| + |
preferred repositories sort earlier in the list.
|
| |
|
| - |
pkgng is also able to work with multiple remote repositories. In the previous section
|
| - |
we are using only a single remote repository, which is defined by the _PACKAGESITE_ option.
|
| + |
To disable the default FreeBSD.conf, create a file
|
| + |
`/usr/local/etc/pkg/repos/FreeBSD.conf` with the contents:
|
| |
|
| - |
In order to be able to work with multiple remote repositories and instead of changing
|
| - |
_PACKAGESITE_ each time, you can tell *pkg(8)* to work in multi-repos mode as well.
|
| + |
```
|
| + |
FreeBSD: { enabled: no }
|
| + |
```
|
| |
|
| - |
To do this, simply enable multi-repos in *pkg.conf(5)* like this:
|
| + |
To check quickly what repositories you have onfigured, run `pkg -vv`.
|
| |
|
| - |
# echo "PKG_MULTIREPOS : YES" >> /usr/local/etc/pkg.conf
|
| + |
See *pkg.conf(5)* for details of the format of `pkg.conf` and the
|
| + |
per-repository `repo.conf` files. See *pkg-repository(5)* for more
|
| + |
details about package repositories and how to work ith them.
|
| |
|
| - |
The next thing is to define your remote repositories in the *pkg.conf(5)* file.
|
| + |
Note that the old style of setting _PACKAGESITE_ in pkg.conf is
|
| + |
no-longer supported. Setting _PACKAGESITE_ in the environment has
|
| + |
meaning for the pkg(7) shim, but is ignored by pkg(8).
|
| |
|
| - |
Below is a part from example configuration file, which defines three remote repositories - *repo1*, *repo2* and
|
| - |
the *default* repository.
|
| + |
Then fetch the repository catalogues using the command:
|
| |
|
| - |
repos:
|
| - |
default : http://example.org/pkgng/
|
| - |
repo1 : http://somewhere.org/pkgng/repo1/
|
| - |
repo2 : http://somewhere.org/pkgng/repo2/
|
| + |
# pkg update
|
| |
|
| - |
It is important that you always define a *default* repository - this is the repository that is being
|
| - |
used when no remote repositories are specified via the `-r <repo>` flag.
|
| + |
This would fetch the remote package database to your local system. Now
|
| + |
in order to install packages from the remote repository, you would use
|
| + |
the `pkg install` command:
|
| |
|
| - |
Next, fetch all the repository catalogues:
|
| + |
# pkg install zsh cfengine3
|
| |
|
| - |
# pkg update
|
| + |
<a name="multirepos"></a>
|
| + |
### Working with multiple repositories
|
| |
|
| - |
And now you can install from the remote repositories using the `pkg install` command like this:
|
| + |
If you have more than one repository defined, then you probably want
|
| + |
to install some packages from a specific repository, but allow others
|
| + |
to be obtained from whatever repository has them available.
|
| |
|
| - |
# pkg install -r repo1 zsh cfengine3
|
| + |
You can install a package from a specific repository:
|
| |
|
| - |
Example repo entries in *pkg.conf(5)* would look like this:
|
| + |
# pkg install -r myrepo zsh
|
| |
|
| - |
default : http://example.com/repos
|
| - |
second : http://somewhere.com/repos
|
| + |
where `myrepo` is one of the tags shown in the `pkg -vv` output. You
|
| + |
can then tell pkg to always use the named repository for upgrades to
|
| + |
that package by:
|
| |
|
| - |
If you want to mirror the repositories and make them public as well, please get in contact with us, so that we
|
| - |
can add your repository to the list as well :)
|
| + |
# pkg annotate -A zsh repository myrepo
|
| |
|
| |
<a name="pkgupdate"></a>
|
| |
### Updating remote repositories
|
| |
|
| - |
The first thing to do when working with remote repositories is to update from them.
|
| - |
|
| - |
Updating remote repositories is done by the `pkg update` command.
|
| + |
The first thing to do when working with remote repositories is to
|
| + |
update from them.
|
| |
|
| - |
If _PACKAGESITE_ environment variable is defined to point to a remote package
|
| - |
repository then only this repository will be updated. Otherwise all remote
|
| - |
repositories defined in the /etc/pkg/repositories file will be updated.
|
| + |
Updating remote repositories is done by the `pkg update` command. By
|
| + |
default his will first update the local copies of the repository
|
| + |
catalogues, unless you specifically configure pkg(8) otherwise.
|
| |
|
| |
So, to update your remote repositories, you would execute this command:
|
| |
|