aMSN plugins

[Garrick Staples]

On Mon, Jul 10, 2006 at 06:59:31PM +0200, Sander Hoentjen alleged:
> On Mon, 2006-07-10 at 08:41 -0700, Garrick Staples wrote:
> > On Mon, Jul 10, 2006 at 05:15:22PM +0200, Sander Hoentjen alleged:
> > > Hi,
> > > 
> > > I am currently the packager of aMSN (and I intend to stay that). aMSN is
> > > an msn clone in a sense that it tries to mimic the looks and
> > > functionality of the official client, and more. For the more bit aMSN is
> > > extensible with various plugins. The upstream release tarball always has
> > > a few plugins included, so i made amsn and amsn-plugins from that
> > > source. There is also module in cvs with extra skins and plugins, and
> > > there exist various plugins and skins contributed by users. Should i
> > > create 2 extra packages, one for skins, and one for plugins, or a
> > > package for each skin/plugin?
> > 
> > I say, follow the dependencies.  If skins and various plugins have
> > different external deps, then seperate them.  You want to avoid the
> > situation where there are lots of unwanted deps to get at 1 plugin.
> > 
> > If a source package creates 10 plugins, 9 have no external deps, and the
> > 10th requires some libfoo, than the 9 should be in 1 package, and the
> > 10th in a seperate package.
> Ok, that makes sense
> > 
> > Don't needless seperate each skin and plugin into different packages;
> > that it just annoying for the user.
> > 
> > 
> > > Also if one package for all plugins should be created how should i call
> > > it, something like amsn-plugins-extra or should i remove the
> > > amsn-plugins from the amsn.spec and include those plugins in
> > > amsn-plugins.spec
> > 
> > Depends on the development.  Can plugins be built without a main -devel
> > package?  Are main and extras developed and released at different rates?
> > Do the upstream docs make a clear seperation between main and extras?
> > Do upstream packages establish a precedent?
> 
> Ah I just thought of another thing, most plugins are noarch (like a
> SpellCheck plugin, just an xml and a tcl file, with dependency on
> aspell). Actually, all plugins I know are noarch, except for 1, and I
> won't package that one because it kind of sucks. Plugins *can* be arch
> specific though, so I should separate those out. Before I mentioned that
> SpellCheck has a dependency on aspell, and that is true in a sense that
> you can fill out a path to a binary that does the translating in an
> ispell compatible way. If you don't have the binary, the plugin just
> does nothing. Most plugins have dependencies that way, another good
> example is the music plugin, it sets your personal message according to
> whatever song you are listening to. It works with xmms, amarok,
> rhytmbox, banshee, mpd. For the music plugins it seems obvious I
> shouldn't require all 5 players, but what should be the require for the
> SpellCheck plugin?

You can go either way with SpellCheck.  I'd say that if a missing ispell
is very apparent to the user, then just keep it with the other plugins
and don't worry about it.  If, from the viewpoint of the user, the
plugin would just appear broken, then seperate it and require aspell.

-- 
Garrick Staples, Linux/HPCC Administrator
University of Southern California
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20060710/d1381d63/attachment.sig>