Hi Carnė,
I've put the other uploaders in CC and would like them to comment, thank
you.
On Wed, Feb 06, 2019 at 04:36:10PM +0000, Carnė Draug wrote:
> On Wed, 6 Feb 2019 at 15:43, Andreas Tille <andreas@an3as.eu> wrote:
> >
> > > > 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.
OK. What do the other Uploaders think?
I'd rather not upgrade it too with close freeze for release. We may find too many problems unresolvable in this timeframe.
Olivier
> 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.
Would you volunteer to co-maintain the package inside Debian. Please
note: I *never* used BioPerl (except in an extremely small example for
a colleague several years ago), I'm neither a Perl programmer nor a
biologist / bioinformatican. Looks like I'm quite badly qualified for
maintaining that package but its like with so many (too many??) other
Debian Med packages I also do not use: I'm just doing it since nobody
else is doing it otherwise. In close to all cases it is sensible to
upgrade Software with micro version changes - in this case it was wrong.
For me the most reasonable thing would be now if you put your name
instead of mine into the Uploaders field (and other non-active uploaders
remove their IDs to not have fake metadata on this package). My goal
general goal for Debian Med package is to gather *competent* people to
do a sensible job on the packages (thus I'm probably the worst choice
here and you are way better). Would you volunteer to take over?
Whatever you decide for the migration of 1.7.4 I'm fine with it.
> 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.
I'd love if we can stop distributing buggy packages.
> > > 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.
I did not addressed it since I have no idea what to answer, sorry. May
be the other Uploaders can comment on it. Its another proof that we are
lacking competence here and I'd love to change this.
Thanks a lot for pointing the finger in the current problems
Andreas.
--
http://fam-tille.de