[Bioperl-l] BioPerl 1.6 RC1

[Sendu Bala]

Alex Lancaster wrote:
>>>>>>>> "SB" == Sendu Bala writes:
> Also can you clarify the expected name of the tarball, is it bioperl,
> or BioPerl?  The 1.5.2 release used bioperl-1.5.2_102.tar.bz2 whereas
> 1.5.9._1 uses BioPerl-1.5.9._1.tar.bz2 and it would be good if there
> was consistency as it really helps from maintaining the packages and
> generating links etc.

Naming consistency is built into the system.
./Build dist
generates a file named:
bioperl-1.5.9_1.tar.bz2

I guess Chris decided to rename the file before uploading, and its up to 
him what future files are named, but I second your suggestion this 
should be consistent.

Chris: I note that extraneous files like 'test.txt' and others made it 
into the RC1 .tar.gz you uploaded. What I always did was a clean export 
of the tag and built from there. BTW, the dist action also warns you 
about modules with their own version: Bio::DB::GFF::Aggregator::orf in 
this case. You might want to investigate that.


> SB> There would most likely be a single CPAN bundle specifying all the
> SB> different BioPerl packages but without any version number
> SB> specifications. When a user installs the bundle it would install
> SB> the latest version of each package.
> 
> SB> Each individual sub-package, on the other hand, would specify the
> SB> version of any other sub-packages or core that it depends on.
> 
> OK, right.  So if any of the sub-packages were incremented
> independently, would a new bundle be generated, or would new bundles
> only be updated for major releases?  Hmm, I'm not sure if subpackages
> with different version numbers from the main package can be generated
> from a single SRPM, so that might be a bit tricky.  But if core is
> only a small number of CPAN pakcages, that might not be so bad,
> although it would mean having to go through review for each of the
> (new) CPAN modules and more maintainance, so it might be a while
> before it would be in Fedora.  When is this scheduled to happen?
> (post-1.6, I hope!)

'core' will only ever be one CPAN package (one tarball).
A new bundle would not be generated when a sub-package is incremented. 
The whole point of sub-packages is that they're independent and can be 
developed and released without affecting core or the other sub-packages.

The only reason for a bundle update would be to add more new 
sub-packages to it.

Again, how does Fedora currently emulate CPAN Bundles?


Just so we're not getting our wires crossed, in this context 'core' 
would be BioPerl-1.5.9._1.tar.bz2 and 6 examples of sub-packages would 
be the .tar.bz2 distribution files for Bio::Graphics, 
Bio::ASN1::EntrezGene, BioPerl-run, BioPerl-db, BioPerl-network and 
BioPerl-ext.

The kind of thing that could then happen in the future is that (to take 
some random imaginary examples) BioPerl-1.7.0.tar.bz2 is released as 
'core' which is a bit smaller than BioPerl-1.5.9._1.tar.bz2 because 
Bio::Structure is missing from it, and there is a new independent 
sub-package released for Bio::Structure, just like what happened with 
Bio::Graphics.


>> "Requires: perl(Bio::Graphics)"
> 
> RPM has a script with heuristics that search .pm and .pl files for
> 'use <module-name>' type constructs to automatically generate
> 'Requires", that sometimes guess wrong.  To check, I grepped an
> exploded package for instances of 'Bio::Graphics' and what returned is
> below, at the end of the e-mail.  I suspect that the 'use
> Bio::Graphics' in some of the installed scripts in bin/ such as
> bp_glyphs2-demo.pl are causing the issue.  Shouldn't these scripts
> perhaps be moved to the Bio::Graphics CPAN module (along with the
> scripts in examples/)?

Thanks for pointing that out. I'll leave it to Chris to sort that out...


> If the Bio::Graphics is truly not needed, for the moment it is
> possible to also override and filter out the bogus Requires until such
> time as these scripts are moved to the appropriate place.

Great, go ahead and do that if you like.