[Bioperl-l] BioPerl 1.6 RC1
bix at sendu.me.uk
Mon Dec 29 21:31:43 EST 2008
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.
generates a file named:
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
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
>> "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.
More information about the Bioperl-l