On Mon, May 24, 2010 at 9:10 PM, Jon Dowland <j...@debian.org> wrote:
> I have a package of bup - a git-based backup tool - sitting in the NEW > queue. bup is 99% python, with a small .so module for some > speed-critical code. > > I decided to have an architecture: all bup-common package for the > majority of the program, and a small architecture: any package for the > .so module, which depends on the -common package. I did this mostly to > see how hard it was, and to see whether it would save mirror space. I would do the packages the other way around; bup with python stuff and bup-something for the .so. I did that for fonttools and I think it makes more sense. > Is this worth the added complexity of two binary packages? Are there > other advantages/disadvantages to consider? >From the ftp-master REJECT FAQ[1]: Package split You split a package too much or in a broken way. Well, broken or too much is a wide definition, so this is a case-by-case thing, but you should really think about a split before you do it. For example it doesn't make any sense to split a 50k arch:all package from a 250k arch:any one. Or splitting a package for only one file, depending on the main package. Yes, big dependency chains can be a reason. Or big documentation splitted into one -doc package. The point there is big. Personally I base my splitting on lintian's warning. http://ftp-master.debian.org/REJECT-FAQ.html -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilowclrualloeo7chzknslfyo7fmutbwxlmg...@mail.gmail.com
