RFC: shipping external-tree plugins

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
|> plugins.
|
| 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
|> package.
|
| 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-core
|>      bzrtools
|>      bzr-gtk ?
|>      etc.
|
| 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
| solve.
|
|> 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
| orthogonal
|
| -Rob

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.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiRGZcACgkQJdeBCYSNAAPRhwCfdPUMviEeBz7W0NF9mOP+B6xt
yZIAn3eFhwLsT/xToY2eqxzN5u5BLkXk
=ijVI
-----END PGP SIGNATURE-----