Bundling more plugins into bzrtools

[Wichmann, Mats D]

> There is the one-time cost of writing suitable descriptions
> for each of those packages, checking them for errors, 
> sending them through our review process, doing the initial
> import and build.  Then there is the recurring cost of 
> rebuilding them whenever a distro-wide event requires it. 
> For instance, when we switched from python-2.4 to 
> python-2.5 we had to rebuild all of our packages. 
> The packager would have to kick off a rebuild for each 
> package in this situation instead of just one. 

You know, I really have to ask the question of whether
this is the right model.  Once the base package is in
place, is it really necessary for every distro to have
to bundle every plugin that might be interesting, or
alternatively, to have useful plugins unavailable because
one or more distros couldn't get around to packaging it?
Once you have a sensible plugin API, there ought to be
other ways to fetch the plugins (as in fact you can do
now, by branching the plugins in your .bazaar/plugins
directory, but that's not very elegant from an end-user
point of view).  There are numerous software systems 
that in fact manage plugins in a user-friendly way, 
I'm thinking Firefox and Eclipse to start with.

> Another
> rebuild example (worse because it required patching the
> package spec files) came when bzr started including 
> compilable modules for speed. Since Fedora is a multilib 
> distro, all the plugin packages had to be switched to 
> storing their files in /usr/lib64/[...]/bzrlib on x86_64
> instead of /usr/lib/[...]/bzrlib.

Yes, this is a horrid problem with Python in general.