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

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
| improve this answer | |
  • 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 '16 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. – Stephen Kitt Nov 8 '16 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 '16 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. – Stephen Kitt Nov 8 '16 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. – Stephen Kitt Nov 8 '16 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
| improve this answer | |
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 <debian-gcc@lists.debian.org>
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

| improve this answer | |
  • 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 '16 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. – Stephen Kitt Nov 8 '16 at 16:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.