[Bioperl-l] Smaller Bioperl Modules

[Alex Lancaster]

>>>>> "CF" == Chris Fields  writes:

CF> On Jul 25, 2008, at 9:50 AM, Alex Lancaster wrote:

>>>>>> ...
>> I concur.  It's definitely a major issue for package maintainers.
>> If you split up bioperl into too many little CPAN modules, it will
>> make packaging bioperl via RPMs in Fedora (or other distros, I
>> suspect) a real pain.  In Fedora that would mean that we might have
>> to individually review/build each package separately which would
>> add a lot of overhead.
>> 
>> Some split up along the lines previously discussed seems sensible
>> (into a "core" and "dev", i.e. not more that 3-4 separate modules),
>> but please not 900 CPAN packages... ;)
>> 
>> Alex

CF> So something like what we indicate in the below link would be
CF> okay?

CF> http://www.bioperl.org/wiki/Proposed_1.6_core_modules

Yep, that was what I was referring to as the "previously discussed"
plan, assuming that you end up with 3 tarballs: bioperl{-core} (?),
bioperl-tools, bioperl-dev.

In Fedora-land they would be named:

perl-bioperl (the core package probably doesn't a qualified name as it
is the base package), perl-bioperl-tools, perl-bioperl-dev

That's quite manageable and there is a precendent on most Linux
distros with gstreamer's (Linux's media library) split up of audio
plugins into gstreamer-plugins-{good,bad,ugly}: http://gstreamer.net/
based on quality (and to some extent on the basis of license, but that
shouldn't apply to bioperl).

One question: how would bioperl-run (and the other modules) factor
into this scheme?  Would you just keep those together at the moment?
Would bioperl-run depend only on "core" or would it also need
bioperl-tools or bioperl-dev?

Also could each of these separate packages be updated independently
(i.e have different version numbers in principle)?

Alex