In my last post, I launched my series of posts called “Conary Uncorked” as a means of introducing people to managing a Linux system based on Conary package management. I want to start by describing how to learn about software installed on a Conary-based system.
* What’s installed on my system?
Use conary query, or conary q for short, to determine what is installed on your system. There are several option combinations you can use to refine the search results. Without any other arguments, though, it returns a list of Conary packages and groups installed on the current system along with their current Conary revision values. Conary packages contain the software installed on your system, and groups are used to manage multiple packages together.
*How can I determine what Conary packages install the “Foo” software?
I run into this issue all the time: I know the name of the software, but I don’t know the name of the Conary packages used to install it. Usually it is only a single package, but some software has been built into multiple packages. What I typically do for this is to grep my query for strings that might be used in the package name:
$> conary q | grep foo
* Is package “foo” installed?
When you know the package name, add an argument to the conary query command to query a specific package. If there are results, Conary displays the revision installed. If the package is not installed, Conary says that it is not found. Here are a couple of examples:
$> conary q openssh
openssh=4.7p1–0.1.1–1!openssh.smartcard,!openssh.static_libcrypto]
$> conary q foo
foo was not found
* Where was package “foo” installed from?
The —full-versions option provides sufficient output to determine what revision of the package is installed as well as where it was installed from. However, it may not always be the easiest thing to read for new Conary users, especially because Conary automatically abbreviates parts of the string. The following query shows OpenSSH from Foresight Linux:
$> conary q—full-versions openssh
openssh=/conary.rpath.com@rpl:devel//1//foresight.rpath.org@fl:1-devel//1/4.7p1–0.1.1–1!openssh.smartcard,!openssh.static_libcrypto]
The —info option reveals several pieces of information about the Conary package, including the specific “Label” used to answer the question of where it was installed from. For OpenSSH, the label shows its repository hostname (foresight.rpath.org) and the release branch from that repository (fl:1):
$> conary q—info openssh
Name : openssh Build time: Sun Sep 16 22:15:55 2007
Version : 4.7p1–0.1.1–1 Label : foresight.rpath.org@fl:1
Size : 675106
Pinned : False
Flavor : gnome,ipv6,krb,!openssh.smartcard,
selinux,tcpwrappers is: x86
After working with Conary for a while, you will likely become familiar with the various parts of a Conary verion string and be better able to read the results of —full-versions. I recommend bookmarking Conary:Version String at wiki.rpath.com for reference.
* What files are managed by the “foo” package?
The —ls and —lsl options return a list of the files on the system that are installed and managed by a particular package. The results show absolute paths so the files are easy to locate on the system. Here’s another example using OpenSSH:
$> conary q —ls openssh
/usr/share/doc/openssh-4.7p1/ChangeLog
/usr/share/doc/openssh-4.7p1/INSTALL
/usr/share/doc/openssh-4.7p1/OVERVIEW
/usr/share/doc/openssh-4.7p1/README… (output truncated)
* Can we do that in reverse? What package manages the ”/usr/share/foo/foobar.sh” file on my system?
Use the —path option to determine the package that manages the file in question. This is very useful and highly recommended before arbitrarily modifying files throughout your system. Here is yet another example related to OpenSSH; notice that the option is before the argument:
$> conary q—path /etc/ssh/moduli
openssh:runtime=4.7p1–0.1.1–1!openssh.smartcard,!openssh.static_libcrypto]
* What’s that colon for? Is “openssh:runtime” different than the “openssh” package?
It is different, but part of the same package. When the package name is followed by a colon and another name, such as “openssh:runtime” and “openssh:doc”, this references a component. When the package is first built, Conary separates out the files into components. Each component represents some logical grouping of files within the package, such as everything needed to run the software or the documentation for how to use the software. This gives the flexibility for other packages to resolve dependencies by bringing in components rather than entire packages. It also gives users the freedom to uninstall components that are just taking up space without removing an entire package. But, enough about how awesome Conary can be… how do I know what components make up an installed package?
Use the —troves option to list all the components that are installed as part of a package. A trove is an installable unit on a Conary-based system or Conary repository. Troves include packages and their individual components as well as Conary groups. The following example shows all the troves that are installed for the OpenSSH package:
$> conary q—troves openssh
openssh=4.7p1–0.1.1–1!openssh.smartcard,!openssh.static_libcrypto]
openssh:doc=4.7p1–0.1.1–1!openssh.smartcard,!openssh.static_libcrypto]
openssh:runtime=4.7p1–0.1.1–1!openssh.smartcard,!openssh.static_libcrypto]
* You mentioned dependencies. How can I be sure things still work if I remove a component from my system?
First, Conary warns you if you are about to remove a component that is used to resolve a dependency elsewhere on the system. Conary keeps track of these dependencies for you. Second, you can use the —deps option to display dependency-related information. You can also use —file-deps to list component dependencies at the file level. Results display what the trove “requires” to resolve its own dependencies and “provides” to resolve other packages’ dependencies. You don’t have to track this information unless you really want to do so; trusting Conary’s warnings is usually enough to prevent mistakes when installing and removing software:
$> conary q—deps openssh
$ conary q—deps openssh
openssh=4.7p1–0.1.1–1!openssh.smartcard,!openssh.static_libcrypto]
(output truncated)...
openssh:runtime=4.7p1–0.1.1–1!openssh.smartcard,!openssh.static_libcrypto]
Provides:
file: /usr/bin/ssh-copy-id
file: /usr/bin/ssh-keygen
trove: openssh:runtime
Requires:
abi: ELF32(SysV x86)
file: /bin/sh
soname: ELF32/libc.so.6(GLIBC_2.0 GLIBC_2.1 GLIBC_2.2 GLIBC_2.3 SysV x86)
soname: ELF32/libcom_err.so.3(SysV x86)
soname: ELF32/libcrypt.so.1(SysV x86)
soname: ELF32/libcrypto.so.5(SysV x86)
soname: ELF32/libgssapi_krb5.so.2(SysV x86)
soname: ELF32/libk5crypto.so.3(SysV x86)... (output truncated)
When you need more information from your Conary queries, reference one of the following resources:
* The conary(1) manual page (run the command man conary)
* The conary query page on the rPath Wiki (http://wiki.rpath.com/wiki/Conary:conary_query)
The next “Conary Uncorked” post goes beyond your current system and queries what software is available for installation from Conary repositories across the Internet.
).