Opkg:installedPkgs

TODO: {{#todo: InProgress (11.14.2014-21:17->MD+)|Mike Dean|OE 5,MD}}

The OPKG package management system provides a suite of tools which can be used to perform a variety of useful tasks on OPKG packages. With these tools, you can:

• List files belonging to a package, along with their install locations.
• Find out which package provided a specific file on your filesystem.
• Read the metadata of a package.
• Display the status for packages.
• Find out what depends on a specific package.
• Reinstall packages.

All of these topics are covered by this article.

Background

The capabilities described in this article are often used individually and together to decide what to do when considering updating software, determining what software will need to be installed on another system to provide the same functionality as found on the current system, whether a certain package is really needed on a filesystem, what version of software is installed, where to find the main project for some particular software, to read a description of a software package in order to learn more about it, and more. These capabilities bring OPKG beyond being a simplistic software installation tool; they're the reason it's called a package management system. Learning to take advantage of these capabilities is highly beneficial to anyone doing more than just the most basic tasks with an embedded Linux system.

General Information

The opkg package management tool has many uses. This article is one of a series of articles covering the capabilities of the opkg package management tool. See the last section of this document for other articles in this series.

OPKG: Working With Installed Packages

The capabilities described in this article are all sub-commands of the opkg command. Not all of these commands require root privileges to run, but they do all require the opkg tool.

List Files Belonging to a Package

The files sub-command lists all of the files which belong to a package. Using it is simple:

root@som9x25:~# opkg list packagename

NOTE

Often times, you will want to pipe the output of this command to grep in order to limit your results. Using grep to search for bin can be a quick way to see what executable files are contained in a package, while a grep for etc can tell you the configuration files for a package, and grepping for '/$' will show you what empty directories were installed by a package. There are many trends a quick regular expression can pull from this file list.

Determing Which Package Provides a Certain File

Sometimes you need to know where a file on your filesystem came from. Often times, this is because you want to know what project maintains the file, so that you can turn to its source code. Other times, you will need to know what package to require when creating your own custom package, so that your application will have the dependencies it needs. Or perhaps you find a tool useful, and want to use it on another project, but you didn't install it; for this reason, you need to find out where it came from. Regardless of the reason, the search sub-command can give you this information.

Using this sub-command isn't always as straight forward as other sub-commands. You must remember to provide the full path to the file in question, or you will get no results. You must use the search command on a file, not a directory, or you will get no results. You must also remember to ensure that you're running the search sub-command on an actual file, rather than a symbolic link to a file, or the search will fail. If you need to know the origin of a symbolic link, you need to determine where the ultimately link points, then run root@som9x25:~# opkg search on that instead.

NOTE

Where the symbolic link ultimately points means the actual file it translates to. Some symlinks point to other symlinks, which themselves may point to other symlinks, and so on until the link list finally points to an actual file. This actual file is where the symbolic link ultimately points.

root@som9x25:~# opkg search /full/path/to/file

See the examples in the next section for more information.

Reading the Metadata of an OPKG Package

The info sub-command allows you to view some very useful metadata that's contained in OPKG files. A package name or a glob can be passed to this sub-command:

root@som9x25:~# opkg info package-name

or

root@som9x25:~# opkg info glob

The examples section contains a few examples which clarify this.

Displaying the Status of a Package

The OPKG status of a package will tell you a subset of the information provided by the info sub-command. The information it provides is more targeted towards displaying information about how the package is relevant to the current machine, rather than information that is relevant to the package itself. This command is used like the info command:

root@som9x25:~# opkg status package-name

or

root@som9x25:~# opkg status glob

Again, the examples show more information about this.

Seeing What Depends upon a Package

Often times, you need to know what depends on a package, in order to determine whether you can safely remove the package or not. The whatdepends sub-command comes in handy for this task.

root@som9x25:~# opkg whatdepends package-name

NOTE

This sub-command only works for packages that are currently installed. If you run this on a package that isn't installed, or if you misspell the package name, you will see no output from this command at all.

Reinstalling Packages.

WARNING!

This section isn't finished yet.

Examples

WARNING!

Examples need to be added

Conclusion

WARNING!

A conclusion is needed

Further Information

Where to Go Next

WARNING!

Need more info