Re: Urgent call to BioPerl users (Was: Bug#848236: src:gbrowse: Fails to build from source since bioperl upgrade has broken libbio-graphics-perl)
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: