[Debian-med-packaging] Another issue in test suite of new version of bioperl.

[Carnë Draug]

On Wed, 6 Feb 2019 at 15:43, Andreas Tille <andreas at an3as.eu> wrote:
>
> On Wed, Feb 06, 2019 at 01:35:23PM +0000, Carnë Draug wrote:
> > > On Tue, Feb 05, 2019 at 04:53:44PM +0000, Carnė Draug wrote:
> > > >
> > > > There was a bug on the test for requires_networking.  It should be
> > > > fixed on the 1.7.4 version that was released today.
> > >
> > > Thanks for the pointer - uploaded yesterday.  Any solution for the
> > > issue with bioperl-run (#921495)?
> > >
> >
> > I replied on the bug tracker for that specific issue.
> >
> > But please read the Change file of the release.  There has been a
> > *lot* of changes on the last release.  There's almost no bug fix, it's
> > all about removing modules, removing programs, adding new modules from
> > other distributions, and dropping dependencies.
> >
> > One very nice change is that this release breaks the circular
> > dependence on bioperl-run (bioperl was dependent on bioperl-run which
> > the was dependent on bioperl)
> >
> > Many of the modules removed were moved into separate distributions.
> > But while there's a repository for those new distributions, upstream
> > has not actually made releases.
> > [...]
>
> Hmmm, I admit I have not expected this kind of heavy changes in a micro
> version change release.  I'm tempted to either file an RC bug to block
> migration of this release or even use an epoch to revert that upgrade.
> That's a lot of changes right before the freeze and I do not want this
> to go into Buster.  What solution do you prefer?
>
> BTW, you could help distributors realise these kind of changes by
> choosing a more usual versioning sheme - for instance 1.8.0 or 2.0.0
> would have forced me to read the changes and have prevented me from
> uploading.
>

This "heavy changes" are not really a "micro version change release".
They are the 1.7 series.  It's too much to do it all in one major
release so it was announced that it would span multiple releases.
>From the README file in release 1.7.0:

    Starting immediately after the final 1.6 branch, we will start
    splitting BioPerl into several smaller easier-to-manage
    distributions. These will have independent versions, all likely
    starting with v1.7.0. **We do not anticipate major API changes in
    the 1.7.x release series, merely that the code will be
    restructured in a way to make maintenance more feasible.**

You will even find that notice on the later 1.6 releases which are 5
years old.  That text is no longer on the README file but there is
something similar on the HACKING file.

About a solution, I'm on two minds about what I prefer:

As upstream developer and Debian packager I think it might be better
to not migrate the new version to testing.  These are large changes
and don't seem acceptable during transition freeze.  There's been
almost no bug fix on it (and the few ones are simple to backport) so
the migration effectively just removes modules from Debian that people
may still be using.

But as an actual user of BioPerl, I would prefer the migration because
of the lesser dependencies.  Currently, installing bioperl in Debian
brings with it a crapload of dependencies.  BioPerl-Run not even works
properly because many of its dependencies are not packaged and others
are on non-free.  Also, I question how many people use the removed
modules which are not particularly useful (but I'm only one user)
which as a developer I also know to be quite buggy.

> > Also, note that in CPAN, this is the BioPerl distribution.  In Debian
> > there's the bioperl source package, the debian bioperl binary package
> > (scripts from that package), and libbio-perl-perl (the perl modules).
> > However:
> >
> >     1) the BioPerl distribution no longer has the Bio::Perl module so
> >     the name libbio-perl-perl would no longer be a good match.
> >
> >     2) upstream does not consider bioperl to be the scripts.  The
> >     scripts are just a secondary thing.  BioPerl main thing are the
> >     modules.  And with the split of bioperl into smaller modules,
> >     there is also bioperl the project which would be all of the
> >     bioperl distributions.

You didn't address this two issues.  These already existed before.
And while the Bio::Perl module did exist before, it was not the main
module of the distribution so the binary package should not have been
named libbio-perl-perl.