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" <[email protected]> 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
