splitting packages

[Ryan Lovett <ryan@stat.Berkeley.EDU>]

Hello,
 A little while back there was some goings on about splitting packages into
foo and foo-common to preserve space on the mirrors. I've noticed that some
packages still have a small amount of architecture dependent files and a
large amount of common files.
 I'm looking into this because I'm thinking about preparing unofficial R
packages for Bioconductor. (www.bioconductor.org) When I look at comparable
packages, for example, perl modules, I see that they're comprised of one
shared library file or program and dozens of non binary module files, man
pages, and other pieces of documentation. Some random packages that fit
this description: libhtml-parser-perl, libxml-parser-perl,
libdbd-mysql-perl.
 When preparing the R modules, should I include the shared library in a foo
package and the rest of non-arch specific stuff in foo-common, or should I
throw everything together as is done with the perl modules? (even though
these will be unofficial packages, I'm hoping that they'll get adopted by
someone eventually.)

Thanks for your time,
Ryan

(Please Cc me as I'm not a subscriber.)