On 4/4/06, Hans de Goede <j.w.r.degoede@xxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
