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
