Re: when to split a package into architecture: all and architecture: any halves
On Mon, May 24, 2010 at 9:10 PM, Jon Dowland <jmtd@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
Reply to: