Opkg:installedPkgs

TODO: {{#todo: InProgress (11.14.2014-21:17->MD+);(09.04.2014-17:00->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 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.
• 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 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 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. Or 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. 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 path instead of the path to the symbolic link.

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.

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:~#

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:~#

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 alsa-conf package:

root@som9x25:~# opkg install --force-reinstall alsa-conf

Downloading ftp://10.0.2.196/core2-32/alsa-conf_1.0.28-r0_core2-32.ipk.

Reinstalling alsa-conf (1.0.28-r0) on root.
Configuring alsa-conf.

root@som9x25:~#

Conclusion

WARNING!

A conclusion is needed

Further Information

Where to Go Next

WARNING!

Need more info