Le jeu. 7 févr. 2019 à 08:02, Andreas Tille <ti...@debian.org> a écrit :
> 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 <andr...@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 >
