On Mon, 2007-07-16 at 00:28 +0200, Stefano Zacchiroli wrote: > On Sun, Jul 15, 2007 at 10:48:14PM +0200, Jelmer Vernooij wrote: > > > Any good reason for this being a separate package instead of becoming > > > part of bzrtools? > > Yes, it's a different upstream package. > I was indeed too cryptic, sorry, let me explain. > > I don't want to see a bzr-foo package in the archive for each .py module > available on the internet which provides yet another sub-command for > bzr. I asked under the (wrong) assumption that bzrtools was a Debian > package shipping in a single Debian package several bzr addons. Under > that assumption it seemed reasonable to avoid creating a new package, > bug including your new addons as part of it. Just for clarity: rebase is 7 py files. I do understand now what your point was, though. > Since my assumption was wrong: what about creating a "bzr-addons" Debian > package containing the most used bzr addons out there instead of filing > an ITP for just one? At the moment, there is only one small bzr plugins packaged: bzr-email, which is has under 10 .py files as well. The other plugins for Bazaar that are packaged are relatively large: * bzr-gtk: 52 py files * bzrtools: 39 py files * bzr-svn: 41 py files * bzr-builddeb: 17 py files and so I think deserve their own package. This means that we would end up with just two relatively small packages for bzr-email and bzr-rebase, which I think isn't too bad. If this gets out of hand and we end up with a too high number of packages that each contain a couple of .py files then I think we should reconsider at that point. By that time, tracking and packaging all the individual plugins probably would've become a problem anyway. Cheers, Jelmer
Attachment:
signature.asc
Description: This is a digitally signed message part