On 4/4/06, Hans de Goede <j.w.r.degoede(a)hhs.nl> wrote:
Agreed but that is still no excuse for the sometimes somewhat
bizarre
dep chains. If a package functions fine (although feature limited)
without something and putting this something in launches a (long) extra
depchain and the part which requires this can be seperated into a
subpackage it should be a in subpackage.
Your logic also hits on another packaging policy limitation in Core
which doesn't strongly delineate between hard requirements and
optional functionality which depends on an additional package to be
installed to be functional. The evolution "requirement" on spamassasin
is an example of how the line between hard requirements and optional
functionality is blurred delibrately by the package maintainer to
ensure that evolution installs with the spamassasin support enabled
without additional effort by unsuspecting users. Making the effort
to subpackage functionality further only makes sense if the
application package maintainers are going to stop treating the
runtime optional functionality as hard requirements in the packaging
spec.
-jef