Puppy package database format

Page updated August 22, 2011

The package system for Puppy 5.x (built with Woof) is introduced here:


This page has some notes on the standardised database format used in Puppy. In a Woof-built Puppy, in /root/.packages/ you will see files with names starting with 'Packages-*' -- these are the package database files, one for each repository.

Puppy versions from 2.0 up to and including 4.x use an older database format. They have files 'packages.txt', 'livepackages.txt' and 'alienpackages.txt'. An entry for a package occupies one line and looks like this:
"abiword-2.6.3" "abiword 2.6.3: a nice wordprocessor" ONOFF "Document +fribidi,+gtk+,+goffice,+wv,+enchant 7556K"
Where 'ONOFF' is either 'on' or 'off'.

Translating that to the new format, which is also on one line... Understand though, the new format is not just for PET packages, it is for any distro's packages. The above example is for a PET package, whereas the example given here for the new format is for a Slackware package:
abiword-2.6.3|abiword|2.6.3|5|Document|999K|slackware/ab|abiword-2.6.3-5-i486.tgz|+aiksaurus,+gtk+,+fribidi,+goffice,+enchant,+wv|a nice word processor|slackware|13.1||
Here is a summary of the new format:
You can figure out from the example the purpose of the fields. However, fleshing it out a bit:

abiword-1.2.4 This is the name by which the package is known in the Puppy Package Manager. The convention adopted is the name-version.
This is the name-only.
This is the version.
This is the revision identification of the package. Optional, I don't use this field for PET packages.
Where the application will be listed in the menu. Planned to support sub-categories, for example 'Document;TextEditor'.
The expanded size after installed. Must be postfixed with 'K' or 'M'.
The subdirectory on the repository where the package is to be found. When you create a PET, recommend leave this empty, as the PPM knows the appropriate places to look to download the package.
abiword-1.2.4-5-i486.tgz The full name of the package on the repository.
Dependencies, comma-delimited, preceded with a '+'. A '-' prefix means a conflicting package. Version information not normally required.
a nice word processor A short one-line description.
The distro on which the package was compiled. This also includes Puppy built from that compatible-distro.
Same thing. The distro version on which the package was compiled. This also includes Puppy built from that compatible-distro.

A unique name identifying the repository that holds this package. Currently we are not making any use of this and recommend leave empty.

Extra notes on these fields:
For historical reasons, for PET packages 'pkgname' field is the entire filename without the '.pet'. For PET packages, 'version' is the entire version, without the name and '.pet'. For example package 'abiword-1.2.3-pup2.pet' will have pkgname='abiword-1.2.3-pup2', nameonly='abiword', version='1.2.3-pup2', pkgrelease=''
In the example of 'Document' you can see the same name at the top-level menu at bottom-left of screen. When the package manager installs a package, the .desktop file is edited to conform to this, thus ensuring that an application will always appear in the expected place in the menu.
Our convention is that we only put anything here when we know or suspect that it is not builtin to the base Puppy system -- this avoids a long list of deps. Deps can also optionally specify versions, see further explanation below.
The Woof build scripts, and the Puppy Package Manager in a running Puppy, read these fields to filter-out inappropriate packages. Examples:
Compiled in Ubuntu Jaunty, or a Puppy built from Jaunty binary packages.
haven't specified what version of Ubuntu this package is compiled in, it is deemed compatible with all Ubuntu versions.
This package is deemed compatible with any Puppy. The PPM will always display this package.
This means the same as above. We use this one (both fields empty) for our architecture-independent packages, such as those that are only data/docs or scripts.

Note, Woof and PPM have a "sliding acceptance scale". For example there is an abiword package with 'ubuntu|intrepid|'. If running "Jaunty Puppy" (next version after Intrepid) the PPM may display the older abiword pkg if no exact match found (that is, no 'ubuntu|jaunty|'). If you want to understand more about the algorithm, look at script support/findpkgs in Woof, and /usr/local/petget/filterpkgs.sh for PPM.

Versioned dependencies

This requires Woof released 23 August 2011 or later.
When someone compiles a package and creates a PET, they might want to specify that the dependencies require certain versions.

Also, there are some packages that are kernel-version-sensitive, for example 'dhcpcd' seems to be. I recall a tentative list of such packages being made up some years ago, yes, in this page (search for the word "sensitive"):

I have now implemented versioning support for dependencies in a systematic manner. In the case of the latest 'dhcpcd' package that I have compiled in Drake Puppy (built from Mageia binary packages -- a fork of Mandriva), running a 2.6.39-3 kernel, I have created 'pet.specs' file (package database file included in every PET package) with this content:
dhcpcd-5.2.12-i486-m1|dhcpcd|5.2.12-i486-m1||BuildingBlock|176K||dhcpcd-5.2.12-i486-m1.pet|+linux_kernel&ge2.6.39|network connection client daemon|mageia|1||
Here is another hypothetical package:
abiword-2.8.6-w5|abiword|2.8.6-w5||Document|7012K||abiword-2.8.6-w5.pet|+cairo,+enchant,+fribidi,+geany,+goffice&eq0.8.9,+gtk+,+libgsf,+libxml,+wv|The GNOME word processor|puppy|wary5||
It is very simple. You only need to specify a version for a dependency when you know or suspect the repo may have alternate packages, for example more than one 'goffice' and you want to make sure the correct version is installed.

The allowed operators are:
&le &ge &lt &gt &eq
These operators can be chained, for example to specify a range:
Puppy can handle packages from many different distros, and this causes a problem with dependency names, for example one distro may have a package named 'alsa-lib', another 'alsa_lib'. To work around this potential problem, there is a variable PKG_NAME_ALIASES in file PKGS_MANAGEMENT in Woof and also in /root/.packages in a running Puppy -- this is automatically used when searching for dependencies.

Package database files

Each PET package has a file 'pet.specs' in it (at top directory level) with the one-line db data for the package, as explained from the start of this page.

You will notice in Woof and also in /root/.packages in a running Puppy, files named 'Packages-*'. These are the db entries for all the packages on a particular repository.

The PPM looks in those Packages-* to find packages, also to resolve dependencies.

Further information on how a repository is added to Puppy is in the file /usr/local/petget/README-add-repo.htm in a Woof-built Puppy.

...you can also find it in a Woof build system at rootfs-skeleton/usr/local/petget/README-add-repo.htm.


There are tools for creating a PET package, see:


The script 'dir2pet' launches a GUI, 'petspec', located at /usr/sbin, which is a convenient simple way to create a db entry for the package. You can also run 'petspec' directly in a terminal. Screenshot:


I have written a couple of HOWTOs in my blog:

Howto contribute PET packages: http://puppylinux.com/blog/?viewDetailed=00703
Introduction to Petspec: http://puppylinux.com/blog/?viewDetailed=00698

Barry Kauler

(c) copyright 2009,2011 Barry Kauler http://bkhome.org/
Woof logo designed especially for Woof by afgs. See FAQ for legal statement.
No part of this page is to be reproduced anywhere else. I have found that there is a problem where parts of my web pages are being inserted at other sites, then not updated, whereas I am updating my pages regularly. This is not a desirable situation, so please just link to my pages.