Opkg:installedPkgs

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 may:

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 within.

Background

Package management is more than installing and removing software. Package management involves managing dependencies between packages, tracking which packages provide which files, and providing information about a package, such as licensing, a package description, and a homepage for the software. A package management system addresses these needs and provides capabilities to assist a user in managing the software installed on a machine.

The capabilities described in this article are often used both 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.
Determining whether a certain package is really needed on a filesystem.
Determining what version of software is installed.
Determining where to find the main project for some particular software.
Seeking 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 anything more than just the most basic of 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, Further Information, 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 files 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 packages to require when creating your own custom package so that your application will have the dependencies it needs. Perhaps you find a tool useful and want to use it on another project, but since you didn't install it, you don't know where it came from; in this case, you will need to use a tool to find out what package provides it. 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. Here are some rules to follow in order to have success with this sub-command:

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 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 link ultimately points, then run root@som9x25:~# opkg search on that path instead of the path to the symbolic link. The root@som9x25:~# ls -lh symlink_name command will tell you exactly where a certain symlink points, but the symlink may actually point to another symlink rather than the actual file. The readlink command is useful for quickly determining the path to the actual file to which a symlink ultimately resolves. If you have a symlink named, mysymlink, you may invoke the readlink command like this:

root@som9x25:~# readlink -f mysymlink

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 upon 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.

Sometimes packages need to be reinstalled in order to repair damage which was done to them accidentally, whether it was caused by something as simple as mistakes made when tweaking the configuration file, or it was caused by accidentally deleting or overwriting important files that are part of the package. The reinstall command will often fix problems which were caused by these and other mistakes (but not always).

To reinstall a package, run:

root@som9x25:~# opkg install --force-reinstall package-name

Examples

Listing Files in a Package

To list all the files belonging to the bind-utils package:

root@som9x25:~# opkg files bind-utils

Package bind-utils (9.9.5-r0) is installed on root and has the following files:
/usr/bin/dig
/usr/bin/host

root@som9x25:~# 

Listing Only Executable Files in a Package

To list only the executable files in the nano package:

root@som9x25:~# opkg files nano | grep bin

/usr/bin/nano
/usr/bin/rnano

root@som9x25:~# 

NOTE

The above method of listing only the executable files in a package is the short, easy way, but it can miss files if they're not located in a bin/ directory like they should be. To make sure you get a list of all files which are marked as executable within a package, you can use the following command:

root@som9x25:~# for fn in $(opkg files nano); do if [[ -x $fn && ! -d $fn ]];
then echo $fn; fi; done

The much more complex command above does the following:

Lists all of the files in the package.
Iterates over this list, one file path at a time.
1. Checks to see if the path refers to an entity which is marked executable.
2. If the entity is marked executable, it checks to see if it is a directory (directories are always executable).
3. If not a directory, it outputs the path on standard output.
Continues iterating until the list is exhausted.

Finding Out Which Package Provides a File

To search for the package which contains a file, you must provide the full path to the file:

root@som9x25:/usr/bin# opkg search $PWD/lastlog

shadow - 4.2.1-r0
root@som9x25:/usr/bin# cd /
root@som9x25:/# opkg search /bin/bash

bash - 4.3-r0

root@som9x25:/# 

Getting Metadata About a Package

To get the metadata for the alsa-conf package:

root@som9x25:~# opkg info alsa-conf

Package: alsa-conf
Version: 1.0.28-r0
Status: install user installed
Section: libs/multimedia
Architecture: core2-32
Maintainer: EMAC <support@emacinc.com>
MD5Sum: 829960ff917f93a60bf0c30ac3ef3390
Size: 18410
Filename: alsa-conf_1.0.28-r0_core2-32.ipk
Source: ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.0.28.tar.bz2 file://Check-if-wordexp-function-
is-supported.patch file://fix-tstamp-declaration.patch file://0001-pcm-route-Use-get32-for-multi-source-
route-calculati.patch file://0001-pcm-rate-fix-hw_ptr-exceed-the-boundary.patch file://0001-pcm-
pcm_local.h-include-time.h-to-enable-CLOCK_MONOT.patch
Description: ALSA sound library  ALSA sound library.
Installed-Time: 1416257204

root@som9x25:~# 

Note the list of files shown as the Source: for the package. This list shows the source code tarball which was used to compile the package, and the list of patches which were applied to the source code tarball before compiling the package.

Getting Status Information for a Package

To get the status information for the alsa-conf package:

root@som9x25:~# opkg status alsa-conf

Package: alsa-conf
Version: 1.0.28-r0
Status: install user installed
Architecture: core2-32
Installed-Time: 1416257204

root@som9x25:~# 

Note that this is a subset of the information which was provided by the info sub-command.

Viewing the Dependents of a Package

To see what depends upon the alsa-conf package:

root@som9x25:~# opkg whatdepends alsa-conf

Root set:
  alsa-conf
What depends on root set
        libasound2 1.0.28-r0    depends on alsa-conf
        alsa-utils-speakertest 1.0.28-r0        depends on libasound2 (>= 1.0.28)
        alsa-utils 1.0.28-r0    depends on alsa-utils-speakertest
        alsa-utils-aseqnet 1.0.28-r0    depends on libasound2 (>= 1.0.28)
        alsa-utils-aseqdump 1.0.28-r0   depends on libasound2 (>= 1.0.28)
        mpg123 1.21.0-r0        depends on libasound2 (>= 1.0.28)

root@som9x25:~# 

Reinstalling a Package

To reinstall the tcpdump package:

root@som9x25:~# opkg install --force-reinstall tcpdump

Downloading ftp://oe50@ftp.emacinc.com/armv5e/tcpdump_4.6.1-r0_armv5e.ipk.
Reinstalling tcpdump (4.6.1-r0) on root.
Configuring tcpdump.

root@som9x25:~# 

Conclusion

The OPKG package management system provides a variety of tools for finding out information about the packages it manages. These tools provide insight into what is provided by a package, what other packages a certain package will pull in, the install status of a package, what other packages depend upon a given package, what packages are installed on a system, what packages are available to install on a system, and the available metadata about any given package. The insight provided by these tools is often essential when customizing a machine to an application.

Further Information

Where to Go Next

Pages with Related Content

The OPKG Package Manager

Opkg:installedPkgs

Contents

Background

General Information

OPKG: Working With Installed Packages

Examples

Listing Files in a Package

Listing Only Executable Files in a Package

Finding Out Which Package Provides a File

Getting Metadata About a Package

Getting Status Information for a Package

Viewing the Dependents of a Package

Reinstalling a Package

Conclusion

Further Information

Where to Go Next

Pages with Related Content

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

OE 5.0 Wiki

OE 4.0 Wiki

Support

Miscellaneous

Tools