4

So, for now, let's say we only need this to work for debian-based systems (but I will need to be able to do it for yum in the future).

The best I have right now is dpkg-query. So, for example, if I run this:

dpkg-query --show

I'll get a list like this (with a few thousand entries):

...  
sudo    1.8.17p1-2  
...  
vim     2:7.4.1829-1  
...

There is no naming convention though. Some of the packages have the version number in them, some of them have the architecture. ex gcc-4.9-base:amd64, but what I want would only have gcc 4.9. Ideally, I would like to be able to get vendor, product, and version information for all of the software installed. Is there any way to do this natively, or does it have to be some kind of "fuzzy" match?

I'm open to alternative ways of querying the package manager, or some other method that I am not thinking of. I am not able to install additional packages to accomplish this goal (though, I would be interested to see how they work if that exists).

3 Answers 3

6

This will list the source packages and versions corresponding to the installed binary packages:

dpkg-query --show -f '${source:Package} ${source:Version}\n' | sort -u

This is the closest match to individual pieces of software you can get automatically: you'll only see gcc-4.9 once, with the associated version, instead of all the corresponding binary packages. You can't easily retrieve "vendor" information, you'd need to look at the package details (apt-cache show ...) or the licensing information (in /usr/share/doc/<package>/copyright — it should point to the "upstream" project, i.e. the "vendor"); this isn't guaranteed to be in machine-readable format so there will be some human parsing involved.

You'll still find some source packages whose name contains the (major) version, e.g. gcc-4.9, gcc-5 etc.; these are unavoidable when packages are designed so that major versions are co-installable, as is the case for GCC.

The equivalent RPM command is

rpm --qf "%{SOURCERPM}\n" -qa | sort -u
7
  • Thanks for explaining the reasoning for the (lack of) naming convention. I suppose that makes sense. The apt-cache could help some of the time, but definitely does not look like something I'd be able to automate as you mentioned (unfortunately). Unless there is a totally new idea somewhere, it looks like dpkg will be the way to go. I can strip out the architecture consistently, but I am getting burned by the extraneous packages that seem to follow the convention product-{lib} or product-{version}, and unfortunately there are many products with a - in their name, so I can't just strip it out
    – Gray
    Nov 8, 2016 at 16:23
  • 1
    If you use the dpkg-query command in my answer, you won't need to remove the architecture, and you'll see far fewer extraneous package names. There's no magic fix for the remaining issues though AFAICS. Nov 8, 2016 at 16:25
  • 1
    It may be better to include the yum version of the command VS rpm: yum list installed. I've always found yum list to be very consistent in it's output, always [package] [version] [repository]
    – Centimane
    Nov 8, 2016 at 16:47
  • 1
    @Centimane the rpm command I gave lists the source packages in a very consistent format; yum list installed lists binary packages, so you can get multiple hits for a single piece of upstream software. Nov 8, 2016 at 16:52
  • 1
    @Gray rqm --querytags will give you all the tags you can use in --qf. The main issue I was trying to address in both cases was to ensure that source packages are listed rather than binary packages, which produces a list tracking software more closely. The result is harder to parse in the RPM case, but needs less filtering than yum list's output. Nov 8, 2016 at 17:46
2

On Debian, perhaps, you could use the option --showformat=format for dpkg-query.

As an exemple :

dpkg-query --show --showformat='${binary:Package}\t${Version}\t${Architecture}\t${binary:Summary}\n' gcc
2

On debian you can run dpkg --list

To get more information about a specific package run:

dpkg -p <package_name>

or

dpkg -s <package_name>

eg:

# dpkg -s gcc 
Package: gcc
Status: install ok installed
Priority: optional
Section: devel
Installed-Size: 42
Maintainer: Debian GCC Maintainers <[email protected]>
Architecture: amd64
Source: gcc-defaults (1.136)
Version: 4:4.9.2-2
Provides: c-compiler
Depends: cpp (>= 4:4.9.2-2), gcc-4.9 (>= 4.9.2-1~)
Recommends: libc6-dev | libc-dev
Suggests: gcc-multilib, make, manpages-dev, autoconf, automake, libtool,  flex, bison, gdb, gcc-doc
Conflicts: gcc-doc (<< 1:2.95.3)
Description: GNU C compiler
This is the GNU C compiler, a fairly portable optimizing compiler for C.
This is a dependency package providing the default GNU C compiler.

On RHEL based distro you can run rpm -qa

2
  • Does dpkg -s/-p source from the same data as apt-cache? Neither of them actually make queries to the repo, right? (I don't want them doing that).
    – Gray
    Nov 8, 2016 at 16:27
  • 3
    It's not the same source of info directly, but ultimately it's the same (apt-cache will be up-to-date as of the last apt-get update, dpkg as of the last dpkg --update-avail; for installed packages the information should be accurate in both cases). Both commands only use local information, they don't access the repositories. Nov 8, 2016 at 16:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .