On Sat, Oct 29, 2005 at 04:18:44AM +0200, Adeodato Simó wrote: > > * Metapackages > > > A metapackage is one of those packages used to pull in other packages. > > If they are removed, it's likely that something goes wrong. They are > > used for various reasons, such as ensuring that one out of many versions > > of a package is installed (like the python modules do) or ensuring that > > a specific set of functionality is present (like the med-* packages). > > Would it be unreasonable to ask that metapackages have to be _empty_, > i.e., that all their functionality it's in their control file? > > Because the idea of tagging 'python' as a metapackage, when it > provides the Python FAQ, the Python Policy, and more importantly, > /usr/bin/python, does not sound too good to me.
Good point. One sure thing (which was my point in the mail) is that a metapackage is not a 'dummy' package in that it's useful to keep it installed. So we can leave my service annoucement behind and discuss what is a metapackage. In the CDD world, a metapackage is something that pulls in other packages as a convenience, but can indeed contain files. One could make a simple CDD by creating a metapackage that pulls in the needed application and also contains some documentation and branding. One could say that a metapackage wouldn't particularly break if its dependencies aren't installed, but it would just be useless. On this definition, 'python' wouldn't be a metapackage in that it would break without its dependencies (i.e., they're real, sound dependencies). This could be a good time to formalize a good definition of metapackage and dummy package. Cc-ing to debian-custom as metapackages are quite a substantial topic over there. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
