On Wed, Nov 27, 2019 at 4:24 PM Andreas Tille <[email protected]> wrote:
> Hi, > > On Wed, Nov 27, 2019 at 12:08:08PM +0000, Carnė Draug wrote: > > On Wed, 27 Nov 2019 at 10:52, Andreas Tille <[email protected]> wrote: > > > > The Bio::Perl module is on the Bio-Procedural repository [1]. No one > > > > has picked up its maintenance and remains unreleased so you won't > find > > > > it on CPAN. > > > > > > Would you volunteer to take over this one? > > > > I'm sorry but I can't. > > > > > If not could you give some > > > short intro what is needed to do to get that module back on CPAN? > > > > Sure. Someone will need to show interest on take over maintenance of > > it. To do so, I would open an issue on the repo [2] saying that I was > > interested. This person will need a PAUSE account [3]. The admin of > > the BIOPERLML on PAUSE (that's cjfields) will need to give permissions > > to that person. > > > > The distribution is already setup to be released with bioperl's dzil > > plugin bundle [4]. The instructions are there. > > > > I think a maintainer should at least address issues #1 [5] and #2 [6] > > before making the release. > > Thanks for the introduction. For me as a non-Perl programmer that's way > to complex since even if I make it through the procedure I could not > take over any maintenance of a Perl module. > > > Also, beware of the following optional dependencies which are not part > > of the core BioPerl distribution (not sure if already packaged in > > Debian): > > > > * Bio::DB::EMBL > > * Bio::DB::GenBank > > * Bio::DB::GenPept > > * Bio::DB::RefSeq > > * Bio::Tools::Run::RemoteBlast > > > > As well as these also optional dependencies which are also not on CPAN > > yet: > > > > * Bio::DB::RefSeq [7] > > * Bio::DB::SwissProt [8] > > Adding some other lib#AvailableOnCPAN#-perl package seems to be a > feasible thing to do, thought. Also if there is some maintained > upstream source outside CPAN should be fine. > > So the question is: > > Do we have some Perl programmer in the Debian Med team who is > willing to follow the procedure described above? > > If the answer is no, what do we do to salvage packages like prokka and > possibly others since it seems the old bioperl is broken appart that > strongly that other packages relying on it will be broken as well. Is > the answer that we revert the version bump any rely on the old > monolithic bioperl or should we talk about the problem with upstreams of > prokka (and may be others) to change their code to only use maintained > bioperl modules? > FYI: Prokka works with the new bioperl just fine. I just saw that the latest roary has a patch for the recent bioperl release, https://salsa.debian.org/med-team/roary/blob/master/debian/patches/new-bioperl-require.patch And indeed, it was the version of roary in testing that was blocking the bioperl transition, so I added a Breaks on old roary to bioperl. -- Michael R. Crusoe
