RFC: shipping external-tree plugins
John Arbash Meinel
john at arbash-meinel.com
Thu Jul 31 02:47:03 BST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Robert Collins wrote:
| On Wed, 2008-07-30 at 16:45 -0700, Colin D Bennett wrote:
|>> I think that if/when bzr bundles plugins we will have to roll point
|>> releases to include fixes to the bundled plugins - its part and parcel
|>> of presenting more code to the user by default.
|> I *strongly* feel that bzr should be available separate from any
| Well it is - from source. Why does it need to be available separately
| though - what does this do to help users?
|> However, can't a distro use a "metapackage" to package bzr
|> with some plugin packages? For instance, on Ubuntu there is
|> 'build-essential' which installs all the important packages to be able
|> to compile and link C programs. On Gentoo, there is the concept of a
|> meta ebuild <http://gentoo-wiki.com/Meta_Ebuild> such as the KDE
| Sure, packaging can be done that way. However downstream packagers
| generally follow the lead of upstreams; we need to be sure we have
| tested the combination we're asking people to install by default.
|> It would make sense to have the following packages, as an example of a
|> possible packaging scheme:
|> bzr-core : this is bzr itself
|> bzrtools : the bzrtools plugin
|> bzr-gtk : the bzr-gtk plugin
|> bzr : a metapackage that depends on the following:
|> bzr-gtk ?
| This is a possible on Debian; but we seem to have a consistent history
| of users not knowing what is available - thats the real bug we need to
|> For instance, if you are setting up a bzr (smart) server, there is no
|> reason to have bzrtools installed on it, right? That's just more
|> things to maintain and be upgraded or break. You might not want to have
|> GTK+ installed on a server, in fact, so no bzr-gtk plugin for you.
| If you have a server, admins will probably want the normal toolchain
| available, so thats a reason to have bzrtools. You certainly do want
| bzr-email installed for instance to send emails on push.
| bzr-gtk, if shipped with bzr (its not in my patch I don't think)
| would probably suggest gtk rather than requiring, though that is
I think the other reason was that packaging overhead makes it harder for
downstreams to package 20 minor plugins and keep the updated form
released when a new bzr is released.
At least, that was the complaint we got from at least 1 packager. He
wanted to see a bunch of plugins brought together because packaging N
was quite difficult. (I think especially once you got into N packages,
against M os versions, by O cpu platforms.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar