wpkg --repository ...


Since version 0.8.0, this option automatically generates an index.tar.gz for you. HOWEVER, it does NOT maintain that index. In other words, if you modify the contents of the repository directory, the index may be out of date and wpkg will not know about that.

The --repository option is used to indicate one or more locations to be used as package repositories. This is used while installing packages so missing dependencies can automatically be gathered from repositories without the need for you to know of all those dependencies necessary to install one specific package.


The --force-depends option actually nullifies the use of the --repository option. This is because when a dependency is missing, the system first checks whether --force-depends was specified and if so, it stops its process right there, allowing the installation of the specified package without requiring it to have all of its dependencies already installed.

The size of the repository is not limited, although wpkg intensively works with memory and thus really large repositories (with thousands of packages) can be problematic at this point. Version 0.7.x read each .deb package and repositories must be direct filenames to directories. Since 0.8.0, the repositories are viewed as local or remote directories (network drives or HTTP repositories,) and the repository index file is used to do most of the work. This means it is a lot faster in determining what dependencies are required to do an installation (i.e. the validation process,) and it uses much less memory.

In older versions (0.7.x), the --recursive option can be used to tell the packager that all the sub-directories defined in the repositories are to be scanned for additional packages. Files from any one of those directories are read as packages if they have the .deb extension. Files that are not valid packages are ignored, however, a file with the .deb extension must be valid packages or an error is generated and the process stops.

Since version 0.8.0, the repository path can use a NetBIOS path or an HTTP path1. For example, if you have a build system that creates nightly builds in a directory named nightly_builds, then you could use something like this after the --repository flag:


With direct path (file://... or smb://...) there is no need for an index to already be available if you have write permissions. However, when you first use the repository, the index is created and thus wpkg is slower to respond to that first request and Later, when you update your repository you'll want to either (1) delete the index; or (2) update it with the --create-index command2.

In case of HTTP, you are required to create the repository index. Without the index, the request command fails because HTTP does not give you an index that is easy to read3. To create the index of your repository, run the wpkg command with or without the --recursive option:

wpkg --create-index index.tar.gz .
wpkg --recursive --create-index index.tar.gz .

You may have any number of layers in the index when using --recursive.


At this time, the resulting file is a compressed tarball. Later we may create an option to create a wpkg specific format that generates a fully optimized index (i.e. files will be pre-sorted, strings compressed in a string table, and compressed control files. These index files could be loaded and used with fast binary searches at once without having to sort anything or parse anything. This would improve the speed even more.


  • 1. Note that most paths specified to wpkg can be direct disk paths or UNC paths, and read only paths can use the HTTP protocol too.
  • 2. It is generally a much better bet to update your repository with the --create-index command because otherwise the first user of your repository may have to wait a long time while the index gets generated, long enough that the user may really wonder whether the command line is blocked for some other reason.
  • 3. Web Servers setup to show the contents of directories, return pages in HTML!
Syndicate content