aMSN plugins

Sander Hoentjen sander at hoentjen.eu
Mon Jul 10 16:59:31 UTC 2006


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?

Sander




More information about the fedora-extras-list mailing list