Re: Urgent call to BioPerl users (Was: Bug#848236: src:gbrowse: Fails to build from source since bioperl upgrade has broken libbio-graphics-perl)
Hi Charles,
Small (but needed) correction: It’s CPAN, CRAN is for R.
I have both a new Bio-Graphics and a test BioPerl-Run up on CPAN, but it looks like there was one additional missing dependency (DB_File) with Bio::Graphics, which I am adding. There are some odd versioning issues with Bio::Graphics that I’m also attempting to reconcile, but the distribution seems to show up fine in CPAN.
chris
On 12/16/16, 6:57 AM, "Charles Plessy" <plessy@debian.org> wrote:
>Hello everybody, and thanks Carnë for the quick answer !
>
>Le Fri, Dec 16, 2016 at 01:06:35PM +0100, Andreas Tille a écrit :
>>
>> On Fri, Dec 16, 2016 at 11:38:02AM +0000, Carnë Draug wrote:
>>
>> > For example, there is now
>> > bio-biblio, bio-eutilities, and bio-coordinates which were previously part
>> > of bioperl itself. The core bioperl is now the bioperl-live distribution.
>>
>> I guess we could document this in README.Debian since I personally do
>> not see a reason to rename the Debian package from bioperl to
>> bioperl-live. Do you think keeping the old name would be confusing for
>> insiders?
>
>At the moment, the bioperl Debian source package produces two binary packages:
>"libbio-perl-perl" provides the libary itself and "bioperl" provides the
>command-line utilities. As long as on CRAN BioPerl is not renamed
>bioperl-live, I think that there is no need to rename the packages. In any
>case, I think that it is good to keep a "bioperl" binary package to install the
>command-line utilities and pull the BioPerl libraries by dependency.
>
>> > There is at least one very important fix on the new bioperl which fixes
>> > the connection to the NCBI servers (although the fix is simple enough
>> > that could be backported).
>>
>> A backport of this fix would be helpful if we really decide to revert
>> the upgrade.
>
>Indeed, if we can just cherry pick patches from GitHub, it would be good to
>apply them in Debian. Can somebody suggest a list of commits ?
>
>> My original proposal:
>>
>> 1. Revert the version bump of bioperl and upload the old version
>> with an epoch (1:1.6.924-6).
>> 2. Upload 1.7.1-2 to experimental
>> 3. Solve all issues with BioPerl 1.7.x after Stretch release.
>> 4. Backport 1.7.x to Stretch once issues are solved.
>>
>> Keeping bioperl 1.7.1 and rather drop other packages:
>>
>> 1. Keep bioperl 1.7.1
>> 2. Drop gbrowse and bioperl-run from Stretch
>> 3. Check all rdepends of bioperl whether they work with 1.7.1:
>> 4. Package as many as the needed tools as we might be able to.
>
>I think that, so close to the Debian stable release, and since some BioPerl
>components have not been released upstream, the original proposal is wiser.
>Debian stable releases last multiple years, so even bioperl 1.7.1 will become
>old eventually. Therefore, I recommend to aim at stability; let's use the
>stable backports once the 1.7.x ecosystem has taken shape.
>
>It would help a lot if the new BioPerl modules were released on CRAN. Debian
>has an amazingly productive Perl team, equipped with many helper tools to
>facilitate packaging, but the main paradigm is to get released sources from
>CRAN. If we need to rely on the head of the master branch of GitHub
>repositories, it will be much harder to ensure consistency, because we can not
>make a package update for every commit.
>
>Have a nice day,
>
>Charles
>
>--
>Charles Plessy
>Debian Med packaging team,
>http://www.debian.org/devel/debian-med
>Tsurumi, Kanagawa, Japan
Reply to: