Posted on 2012-07-26T10:35 by ivoras
FreeBSD (and BSDs in general) traditionally have source-based upgrades and installs which extends to the third party software collections – ports or pkgsrc and similar. This is all fine and offers unprecedended flexibility when tailoring system to specific needs, but sometimes this flexibility is less important than ease of use or time savings which can only be achieved with binary packages. Enter pkgng, the next-generation binary package management system by Baptiste Daroussinand others, which replaces the old-style ports and packages system.
Pkgng has a large palette of features which are simply done right – ranging from using sqlite as the database for storing (and even exchanging) package information, to a very flexible way of using (and creating!) additional package repos (of course, packages are built from existing ports), but the single most important feature which should immediately appeal to anyone who has used ports for a long-ish time is this: it has two-way recursive dependancy tracking.
This is best explained in an example: if you installed apache22 version X and later want to upgrade it to version Y but the package for version Y has a dependancy on a newer version of pcre, it will upgrade both apache22, pcre and all packages depending on pcre in one operation. This is a "matter of course" for Linux distributions but was generally a pain in the ass to achieve with ports. Now, pkgng will do it automagically.
Concerning package versioning, the long-term plans are to establish "stable" sets of packages. This is still a "rolling release" system in the sense that no changes will be backported to previously released sets of packages, but will ensure that a specific package set stays on the repo servers for a certain time – a year or so, which minimizes the need for massive upgrade operations. There are lot of things yet to be defined for pkgng, so this may also change in the future.
You can install pkgng either from ports (in the ports-mgmt/pkg directory) or from a classical old-style package file – it doesn’t matter. To start using pkgng it is best to start from a clean system, without any packages installed, but it can also be achieved by converting existing installed packages/ports to the pkgng format by running pkg2ng.
The next step is to copy /usr/local/etc/pkg.conf.sample to /usr/local/etc/pkg.conf and edit the PACKAGESITE line to an existing repository. Examples of these are:
- http://pkgbeta.freebsd.org/freebsd-9-i386/latest – for i386
- http://pkgbeta.freebsd.org/freebsd-9-amd64/latest – for amd64
After that, the command "pkg update" will update the remote repository data, and everything will be set up for using pkgng.
A new package can be installed from the remote repo by using "pkg install $packagename", e.g.:
# pkg install vim-lite
Updating repository catalogue
Repository catalogue is up-to-date, no need to fetch fresh copy
The following packages will be installed:
Installing libiconv: 1.14
Installing gettext: 0.18.1.1
Installing vim-lite: 7.3.556_1
The installation will require 36 MB more space
10 MB to be downloaded
Proceed with installing packages [y/N]: y
libiconv-1.14.txz 100% 595KB 595.3KB/s 595.3KB/s 00:01
gettext-0.18.1.1.txz 100% 4955KB 991.0KB/s 825.1KB/s 00:05
vim-lite-7.3.556_1.txz 100% 5117KB 1.0MB/s 607.4KB/s 00:05
Checking integrity... done
Installing libiconv-1.14... done
Installing gettext-0.18.1.1... done
Installing vim-lite-7.3.556_1... done
… and a list of packages can be queried with "pkg info":
# pkg info
gettext-0.18.1.1 GNU gettext package
libiconv-1.14 A character set conversion library
pkg-1.0.r4 New generation package manager
vim-lite-7.3.556_1 Vi "workalike", with many additional features (Lite package)
Note that, since a proper database is being used, "pkg info" is finally a fast operation. The rest of the commands are named similary to their old-style counterparts, and the whole list can be viewed simply by running "pkg" without arguments.
That’s it – happy pkgng’ing!
Update:
Pkgng cannot be used simultaneusly with old-style binary packages and with old pkg_* management tools, simply because everything changed: the package format is different and the way the installed packages are tracked is different (and much better). If the two systems are used simultaneusly, all sorts of unwanted and erroneus behaviour will happen: files will be overwritten, dependancies will not be tracked properly, etc. – in short, the two system will fight badly. If you start using pkgng, do not continue to use the pkg_* tools and ports management tools like portupgrade and portmaster.
However, pkgng can coexist with from-source builds of ports by adding the line WITH_PKGNG=yes to /etc/make.conf. This will cause the newly built and installed ports to be registered properly in the pkgng database. While this is an excellent (and very much needed) idea when there is a need for some specific flags and options in ports’s builds, it requires special care when upgrading with pkgng.