On Jan 26, 2008, at 12:08 PM, Daniel Macks wrote: > Do we have any guideline or best-practices for how to structure > (splitoffs, etc) a package that has plugins? By "plugins", I mean > runtime-loaded modules or other components that can be removed without > harming the overall program (other than losing the functionality they > provide). > > I can think of several...would be nice to have some sort of uniformity > so users know what to expect (or at least a way to find what they > want) (or at least "get uesd to" one way) (or at least post this as a > canned answer when a package behaves in a way a user doesn't expect or > like). > > 1. Have the plugin as part of the parent package (example: imagemagick > and its librsvg plugin). Pro 1: installing imagemagick gets a fully > featured package, because the plugins that support standard features > are always present. Pro 2: easy to package if the module's build is > already implemented as part of the parent build process, because the > parts of the distro are built all together. Con: possibly large > dependency chain for just one of the plugins, so package looks bloated > if user does not need that feature. > > 2. Have the plugin as a splitoff of the parent package. Pro 1: binary > users don't have bloated dependencies for the main package. Pro 2: > pretty easy to package. Con 1: source users still need the whole > dependency chain. Con 2: users need to know to install the plugin > (looks like "parent doesn't work right") and perhaps have weird > effects if the installed versions of the plugin and the parent get out > of sync (plugins are often laxer about interface stability because > they often aren't designed as stand-alone/modular public components). > > 3. Have the plugin as part of the library that supports it (example: > evince and its plugin for nautilus). Pro 1: even source users of the > parent don't have dependency bloat. Pro 2: Easy to package if the > plugin build is already implemented as part of the library build > process. Con 1: users of the parent need to know to install the > plugin. Con 2: users of the library get a dependency chain for a > package unrelated to the library. > > 4. Plugin as splitoff of library. Like #3, solving #3 con 2 and > solving #3 con #2 for binary users. > > 5. Build plugin as an entirely separate package (example: mozilla's > librsvg plugin). Pro 1: no dependency bloat for anyone (caveat: con > 2). Con 1: need to know to install. Con 2: need to hack parent to > disable plugin build, including avoiding complaining if dependencies > for it are missing. Con 3: things that "look like" simple plugins may > also involve code in main program (plugin isn't as runtime-modular as > it appears) (related to cons 2 & 4). Con 4: need to hack a way to > build the module itself without building the parent package (typically > involves lots of makefile and flag adjustments). > > dan > > -- > Daniel Macks > [EMAIL PROTECTED] > http://www.netspace.org/~dmacks > I think I would prefer #2 or #4. I think 5 is too much work for the benefits. And probably too hard for me to do :).
I'm not sure I know what I'm talking about yet, but libgda3 (pangocairo) might be a good example of what might get in the way in terms of bloat. It looks like the 'providers' in libgda might be plugins. They do have to be configured and made, but at first glance they might not be linked in the main shlibs, and they do seem to live in a subdirectory of their own. I suspect, though, if I configure the mysql 'provider', configure is going to go looking for mysql headers to link the provider against. I'm sure I don't want to build the whole list of providers by default if that's the case. I think having to explain that a user needs libgda4-shlibs and libgda4-mysql or libgda- whateverbackend isn't too difficult for maintainers or users. As it happens, the somewhat bare libgda + libgda4-shlibs provides an sqlite provider as default. (Maybe even libgda-shlibs by itself -- I just started messing with this this week.) Dave -- David Reiser [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
