Hello > > 'packagesearch' is a package which uses a plugin architecture. Each > > plugin provides a way to search for packages, e.g. doing a full text > > search, searching by filenames or orphaned packages. All plugins are > > shipped together with the main application in a single > > package. However, most of the plugins require some additional packages > > to work (e.g. apt-file or deborphan). If the packages are not > > available, the plugin will detect that, inform the user how he could > > install the package and disable itself. > > I would do this on a case by case basis: recommend some of the > core plugins that do not need additional packages, so that the > framework normally ships with some plugins that work, but even those > can be removed without removing the framework; and suggesting the other > plugins, so people know about them.
That sounds like a reasonable policy for plugin packages to me. It's actually what a lot of totally plugin based software does. I will use that approach for packagesearch. I believe the use of virtual packages is not exactly the most popular thing to do. I remember being advised against it once. Also I don't want the overhead of splitting up the package just yet - there is not much gain coming from that. Thanks to all for the suggestions. Best Regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
