I thought I would followup on this, since I know that imagemagick was one of the examples you had in mind.
I couldn't find a way to get imagemagick to build binaries that enabled plugins, without also building the plugins (and hence dragging in all the unwanted libraries to the build). So what I did was to modify the imagemagick-nox package so that it built *nothing* shared... this makes the package perhaps a bit bloated, but avoids the need for the dependent libraries of the bits being left out. This did have one implication for packaging, however: to avoid conflicts between imagemagick10-shlibs and imagemagick-nox, I moved the plugin files to the main package rather than the shlibs splitoff. The two main packages conflict/replace each other, but only the "x" version cares about a shlib splitoff. -- Dave On Jan 26, 2008, at 9:08 AM, 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 > > > ------------------------------------------------------------------------- > 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 ------------------------------------------------------------------------- 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
