How can I determine if a package is a meta-package from the command line, possibly via apt-get, aptitude or apt-cache?

I have tried:

apt-cache show texlive-full
apt-cache showpkg texlive-full

but the only way I can tell this package is meta is by reading the "en-description" field.

Is there a more automatic way of doing this, that will give me a yes/no response, or at least have a field such as then "en-description" dedicated to this?

  • 1
    Aside from the fact that this question and the answers are quite interesting, why do you want to know this?
    – Joe
    Oct 3, 2012 at 19:51
  • 1
    I was installing stuff with apt-get, and noticed that if I install a metapackage (texlive-full), it installs the dependencies I want, but if I uninstall the metapackage, the dependencies stay there (apt-get install texlive-full, apt-get purge texlive-full; apt-get autoremove). Then I found that this is the case only for metapackages brainstorm.ubuntu.com/idea/17785. aptitude on the other hand does remove the unnecessary dependencies from a metapackage. Oct 5, 2012 at 10:16
  • ismetap () { if [ ! -z "$(apt-cache show $1|grep Section|grep meta)" ]; then echo yes ; else echo no ; fi } should work, no guarantee that it will work for all meta-packages just call it with a package name like this. ismetap packagename Its a bash function so you can cut and past it into a terminal or put it in a bash script.
    – manoflinux
    Aug 10 at 17:16

2 Answers 2


There is no formal definition of a metapackage. The informal definition is that a metapackage is one that is only intended to be installed for its dependencies and contains no useful file of its own.

You can define a metapackage as a package that contains no file. There is no way to determine this from the package database. You can use the file database and check that the package contains only directories (many such packages contain a few directories). In fact, most metapackages contain a few files in /usr/share/doc/<package name>: a copyright file, a changelog, sometimes a few more. Here's an approximation that defines a metapackage as containing only files in /usr/share/doc/<some directory> (not in subdirectories of that) and the leading directories:

if ! apt-file -F list $package | grep -qvE '^/(usr(/share(/doc(/[^/]*(/[^/]*)?)?)?)?)?$'; then
  echo "$package looks like a metapackage"

Another approach is to look for a package tag with debtags. There are several tags that are commonly used on metapackages.

debtags tag ls $package | grep -x -e 'role::metapackage' -e 'role::dummy' -e 'special::meta'

Another approach is to look for packages with a small size. Each directory counts as 4 kB, so plan accordingly when picking a threshold (again, this is an approximation).

aptitude -F '%I %p' search "~n^$package\$"

Upon reflection, I wonder if you mean virtual packages rather than metapackages. Virtual packages are actually not packages but package names used in Provides: fields. You can list them with aptitude search '~v'. Running apt-cache show on one displays “Can't select versions from package 'zcav' as it is purely virtual”. Running aptitude show lists the packages that provide it. A convenient way to show virtual packages is with apt-cache: this prints one line for a non-virtual package and potentially multiple lines (one for each provider) for a virtual package — you can tell if the package is virtual even if there is a single provider because the name of the provider is different.

apt-cache -n search "^$package\$"
  • thanks for those methods: I didn't know about debtags! also, I read somewhere that when you install a metapackage with apt-get, it is exactly as if you had installed each dependency by hand individually, meaning that removing the original package will not immediately remove its dependencies, while for normal packages, remove will remove the installed dependencies. Is this true? If so, how can apt-get tell the difference? This could be exploited too... (also seems that aptitude does not care if its meta or not, is this true?) Sep 27, 2012 at 8:48
  • @cirosantilli The feature of automatically removing dependencies is unrelated to metapackages. This happens because if you don't request a package explicitly, it's marked as automatically installed, and a package marked as automatically installed is removed if no package that depends on it is installed. See apt-get autoremove, aptitude (un)markauto, the M command in the aptitude interactive interface. Sep 27, 2012 at 8:52
  • @cirosantilli Upon reflection, I wonder if you what you had in mind was virtual packages, and not metapackages? See my updated answer. Sep 27, 2012 at 10:30
  • I really didn't know about virtual packages, but I think texlive-full is not virtual since apt-cache show texlive-full shows the usual results. Even so, after I did apt-get install texlive-full, apt-get purge texlive-full; apt-get autoremove did not remove all the installed dependencies. I read somewhere that this is because texlive-full was a metapackage, and that this was normal behaviour of a metapackage, but maybe this was wrong. aptitude on the other hand seemed to remove the automaticlly installed dependencies just fine. Sep 27, 2012 at 16:09

You could try entering

apt-cache search 'metapackage | meta-package'

which will give you a long list, and then use grep to, say show all science related metapackages with

apt-cache search 'metapackage | meta-package' | grep -i science

This will return a long list (I have shortened it here)

science-astronomy - Debian Science Astronomy packages
science-astronomy-dev - Debian Science Astronomy-dev packages
science-biology - Debian Science Biology packages
science-chemistry - Debian Science Chemistry packages
science-dataacquisition - Debian Science data acquisition packages
science-dataacquisition-dev - Debian Science data acquisition development packages
science-distributedcomputing - Debian Science Distributed Computing packages
science-electronics - Debian Science Electronics packages
science-electrophysiology - Debian Science packages for Electrophysiology
science-engineering - Debian Science Engineering packages
science-engineering-dev - Debian Science Engineering-dev packages
science-geography - Debian Science Geography packages
science-highenergy-physics - Debian Science High Energy Physics packages

You can use any number of alternatives for science, such as KDE to find all the KDE metapackages.

This is probably about the best you can do with apt-cache, but it should quickly locate most of the metapackages you want to find. If it doesn't find exactly everything you were looking for, the simplest thing is to look in the metapackage section in Synaptic.

You must log in to answer this question.

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