Opkg:installedPkgs - Revision history

Mgloff at 21:49, 13 July 2017

2017-07-13T21:49:24Z

Kyoungmeyer at 21:46, 10 November 2015

2015-11-10T21:46:25Z

Mgloff at 19:35, 10 November 2015

2015-11-10T19:35:55Z

Mdean: Fixed a few typos.

2015-11-10T16:27:14Z

Fixed a few typos.

Mdean: Marked for Review

2015-11-09T22:41:18Z

Marked for Review

Mdean: in progress.

2015-11-09T21:30:44Z

in progress.

Mdean: Saving to keep from losing it, while going for lunch.

2015-11-09T19:39:41Z

Saving to keep from losing it, while going for lunch.

Show changes

Mdean: Made some minor improvements.

2015-09-04T21:56:32Z

Made some minor improvements.

Mdean: Fixed typo.

2014-11-17T21:20:58Z

Fixed typo.

Mdean: Added examples and finished main content section.

2014-11-17T21:18:39Z

Added examples and finished main content section.

← Older revision		Revision as of 21:49, 13 July 2017
Line 234:		Line 234:
	{{:Templateimpl:whatnext \| initials=MD \| title=OPKG: Working With Installed Packages \| desc=opkg package management \| project=OE 5 }}		{{:Templateimpl:whatnext \| initials=MD \| title=OPKG: Working With Installed Packages \| desc=opkg package management \| project=OE 5 }}
	* [[Opkg\|The OPKG Package Manager]]		* [[Opkg\|The OPKG Package Manager]]
−	* [[Install_the_EMAC_SDK#Install_Using_apt_.28Recommended.29 \| Installing EMAC Packages Using Apt]]

@@ Line 1: / Line 1: @@
-{{todo| Final Draft (11.14.2014-21:17->MD+);(09.04.2014-17:00->MD+);(11.09.2015-13:40->MD+)(11.09.2015-16:40->MD+)(11.10.2015-13:30->MG+)|Mike Dean| project=OE 5,MD,mg,Final Draft }}
+{{todo| Complete (11.14.2014-21:17->MD+);(09.04.2014-17:00->MD+);(11.09.2015-13:40->MD+)(11.09.2015-16:40->MD+)(11.10.2015-13:30->MG+)(11.10.2015-15:45->KY+)|Mike Dean| project=OE 5,MD,mg,Complete }}
 {{#seo:
 |title=OPKG: Working With Installed Packages

@@ Line 1: / Line 1: @@
-{{todo| Review (11.14.2014-21:17->MD+);(09.04.2014-17:00->MD+);(11.09.2015-13:40->MD+)(11.09.2015-16:40->MD+)|Mike Dean| project=OE 5,MD,Review }}
+{{todo| Final Draft (11.14.2014-21:17->MD+);(09.04.2014-17:00->MD+);(11.09.2015-13:40->MD+)(11.09.2015-16:40->MD+)(11.10.2015-13:30->MG+)|Mike Dean| project=OE 5,MD,mg,Final Draft }}
 {{#seo:
 |title=OPKG: Working With Installed Packages

@@ Line 50: / Line 50: @@
 {{usage|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 <code>search</code> sub-command can give you this information.
+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 <code>search</code> 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:
@@ Line 58: / Line 58: @@
 * You must remember to ensure that you're running the <code>search</code> 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 {{icli|opkg search}} on that path instead of the path to the symbolic link.  The {{icli|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 <code>readlink</code> command is useful for quickly determining the path to the actual file to which a symlink ultimately resolves.  If you have a symlink named, <code>mysymlink</code>, you may invoke the <code>readlink</code> command like this:
+If you need to know the origin of a symbolic link, you need to determine where the link ultimately points, then run {{icli|opkg search}} on that path instead of the path to the symbolic link.  The {{icli|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 <code>readlink</code> command is useful for quickly determining the path to the actual file to which a symlink ultimately resolves.  If you have a symlink named, <code>mysymlink</code>, you may invoke the <code>readlink</code> command like this:
 {{cli |readlink -f mysymlink}}
@@ Line 91: / Line 91: @@
 {{usage|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 <code>whatdepends</code> sub-command comes in handy for this task.
+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 <code>whatdepends</code> sub-command comes in handy for this task.
 {{cli|opkg whatdepends ''package-name''}}

@@ Line 1: / Line 1: @@
-{{todo| InProgress (11.14.2014-21:17->MD+);(09.04.2014-17:00->MD+);(11.09.2015-13:40->MD+)|Mike Dean| project=OE 5,MD }}
+{{todo| Review (11.14.2014-21:17->MD+);(09.04.2014-17:00->MD+);(11.09.2015-13:40->MD+)(11.09.2015-16:40->MD+)|Mike Dean| project=OE 5,MD,Review }}
 {{#seo:
 |title=OPKG: Working With Installed Packages
@@ Line 7: / Line 7: @@
 }}
-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:
+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.
@@ Line 16: / Line 16: @@
 * Reinstall packages.
-All of these topics are covered by this article.
+All of these topics are covered within.
@@ Line 37: / Line 37: @@
 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.
 {{:Templateimpl:geninfo | initials=MD | title=OPKG: Working With Installed Packages | desc=opkg package management | project=OE 5 }}
-The <code>opkg</code> package management tool has many uses.  This article is one of a series of articles covering the capabilities of the <code>opkg</code> package management tool.  See the last section of this document, Further Information, for other articles in this series.
+The <code>opkg</code> package management tool has many uses.  This article is one of a series of articles covering the capabilities of the <code>opkg</code> package management tool.  See the last section of this document, [[Opkg:installedPkgs#Further_Information|Further Information]], for other articles in this series.
 {{:Templateimpl:using | initials=MD | title=OPKG: Working With Installed Packages | desc=opkg package management | project=OE 5 }}
@@ Line 226: / Line 226: @@
 {{:Templateimpl:conclusion | initials=MD | title=OPKG: Working With Installed Packages | desc=opkg package management | project=OE 5 }}
-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,
+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.
 {{:Templateimpl:moreinfo | initials=MD | title=OPKG: Working With Installed Packages | desc=opkg package management | project=OE 5 }}
-* {{warning|Need more info}}
+* [[opkg:configuration|Configuring the Package Manager]]
 {{:Templateimpl:whatnext | initials=MD | title=OPKG: Working With Installed Packages | desc=opkg package management | project=OE 5 }}
+* [[Opkg|The OPKG Package Manager]]

@@ Line 110: / Line 110: @@
 To list all the files belonging to the <code>bind-utils</code> package:
-{{clo}}
+{{clop}}
-{{clio|opkg files bind-utils}}
+{{cliop|opkg files bind-utils}}<nowiki>
-Package bind-utils (9.9.5-r0) is installed on root and has the following files:<br />/usr/bin/dig<br />/usr/bin/host<br />
+Package bind-utils (9.9.5-r0) is installed on root and has the following files:
-{{clio|}}
+/usr/bin/dig
-{{clos}}
+/usr/bin/host
 {{example|Listing Only Executable Files in a Package}}
 To list only the executable files in the <code>nano</code> package:
-{{clo}}
+{{clop}}
-{{clio|opkg files nano {{!}} grep bin}}
+{{cliop|opkg files nano {{!}} grep bin}}<nowiki>
-/usr/bin/nano<br />/usr/bin/rnano<br />
+/usr/bin/nano
-{{clio|}}
+/usr/bin/rnano
-{{clos}}
+</nowiki>
 {{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 <code>bin/</code> 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:
@@ Line 141: / Line 146: @@
 {{example|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:
-{{clo}}
+{{clop}}
-{{clio|opkg search $PWD/lastlog|pwd=/usr/bin}}
+{{cliop|opkg search $PWD/lastlog|pwd=/usr/bin}}<nowiki>
-shadow - 4.2.1-r0<br />
+shadow - 4.2.1-r0</nowiki>
 {{clio|cd /|pwd=/usr/bin}}
-{{clio|opkg search /bin/bash|pwd=/}}
+{{cliop | pwd=/ |opkg search /bin/bash}}<nowiki>
-bash - 4.3-r0<br />
+bash - 4.3-r0
-{{clio||pwd=/}}
+</nowiki>
-{{clos}}
+{{cliop||pwd=/}}
 {{example|Getting Metadata About a Package}}
@@ Line 167: / Line 173: @@
 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.<br />Installed-Time: 1416257204
+Description: ALSA sound library  ALSA sound library.
 </nowiki>
 {{cliop|}}
@@ Line 206: / Line 213: @@
 {{example|Reinstalling a Package}}
-To reinstall the alsa-conf package:
+To reinstall the <code>tcpdump</code> package:
 {{clop}}
-{{cliop|opkg install --force-reinstall alsa-conf}}<nowiki>
+{{cliop|opkg install --force-reinstall tcpdump}}<nowiki>
-Downloading ftp://10.0.2.196/core2-32/alsa-conf_1.0.28-r0_core2-32.ipk.
+Downloading ftp://oe50@ftp.emacinc.com/armv5e/tcpdump_4.6.1-r0_armv5e.ipk.
-Reinstalling alsa-conf (1.0.28-r0) on root.
+Reinstalling tcpdump (4.6.1-r0) on root.
-Configuring alsa-conf.
+Configuring tcpdump.
 </nowiki>
 {{cliop|}}
@@ Line 218: / Line 225: @@
 {{:Templateimpl:conclusion | initials=MD | title=OPKG: Working With Installed Packages | desc=opkg package management | project=OE 5 }}
-{{warning|A conclusion is needed}}
 {{:Templateimpl:moreinfo | initials=MD | title=OPKG: Working With Installed Packages | desc=opkg package management | project=OE 5 }}

@@ Line 1: / Line 1: @@
-{{todo| InProgress (11.14.2014-21:17->MD+)|Mike Dean| project=OE 5,MD }}
+{{todo| InProgress (11.14.2014-21:17->MD+);(09.04.2014-17:00->MD+)|Mike Dean| project=OE 5,MD }}
 {{#seo:
 |title=OPKG: Working With Installed Packages
@@ Line 22: / Line 22: @@
 {{:Templateimpl:bg | initials=MD | title=OPKG: Working With Installed Packages | desc=opkg package management | project=OE 5 }}
-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.
+The capabilities described in this article are often used both individually and together to decide what to do when:
 {{:Templateimpl:geninfo | initials=MD | title=OPKG: Working With Installed Packages | desc=opkg package management | project=OE 5 }}
 The <code>opkg</code> package management tool has many uses.  This article is one of a series of articles covering the capabilities of the <code>opkg</code> package management tool.  See the last section of this document for other articles in this series.
@@ Line 37: / Line 47: @@
 {{usage|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 <code>search</code> sub-command can give you this information.
+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 <code>search</code> 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 <code>search</code> command on a file, not a directory, or you will get no results.  You must also remember to ensure that you're running the <code>search</code> 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 {{icli|opkg search}} on that instead.
+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 <code>search</code> command on a file, not a directory, or you will get no results.  You must also remember to ensure that you're running the <code>search</code> 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 {{icli|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.}}

@@ Line 32: / Line 32: @@
 The <code>files</code> sub-command lists all of the files which belong to a package.  Using it is simple:
-{{cli|opkg list ''packagename''}}
+{{cli|opkg files ''packagename''}}
 {{note|Often times, you will want to pipe the output of this command to <code>grep</code> in order to limit your results.  Using <code>grep</code> to search for <code>bin</code> can be a quick way to see what executable files are contained in a package, while a <code>grep</code> for <code>etc</code> can tell you the configuration files for a package, and <code>grep</code>ping for <code>'/$'</code> 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.}}
@@ Line 77: / Line 77: @@
 {{usage|Reinstalling Packages.}}
-{{warning|This section isn't finished yet.}}
+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).
 {{:Templateimpl:examples | initials=MD | title=OPKG: Working With Installed Packages | desc=opkg package management | project=OE 5 }}
-{{warning|Examples need to be added}}
 {{:Templateimpl:conclusion | initials=MD | title=OPKG: Working With Installed Packages | desc=opkg package management | project=OE 5 }}