Re: removing tophat from Debian
On 21.12.17 04:41, Afif Elghraoui wrote:
On December 20, 2017 5:17:20 AM EST, Michael Crusoe <email@example.com> wrote:
2017-12-16 10:18 GMT+02:00 Afif Elghraoui <firstname.lastname@example.org>:
Given the statement from the website 
Please note that TopHat has entered a low maintenance, low support
stage as it is now largely superseded by HISAT2 which provides the
same core functionality (i.e. spliced alignment of RNA-Seq reads),
in a more accurate and much more efficient way
This statement is about TopHat 2, which is what is in the Debian
and a statement from one of its co-authors 
Please stop using Tophat. Cole and I developed the
method in *2008*. It was greatly improved in TopHat2 then HISAT
& HISAT2. There is no reason to use it anymore. I have been
saying this for years yet it has more citations this year than last
This more strongly worded statement is about TopHat 1, which is not in
The summary of the statement is that hisat2 is the only one of those 4 that isn't obsolete, and therefore that it's the only one of those 4 that should be used.
We should retain TopHat2, perhaps with a note about HISAT2.
I think tophat2 (and hisat1 if we have it) should also be removed. We should get upstream involved if you still disagree.
So, what could justify a deprecated piece of software in Debian. To mind
* an API change
* a well-established tutorial that was not yet updated
* historic landmarks achieved by that software that one wants to
compare new developments against
I have difficulties with the role of our distribution as some kind of
package-value police. My personal
threshold for sponsoring is a peer-reviewed publication. But I like the
role of our distribution as a communicator.
And we should indeed collect ideas on how to spread the news on a better
alternative - any clear cut
improvals are rare enough, though.
If upstream explicitly asks for a removal from our distribution, then I
am still hesitating. Do they also
retract their publication? Most likely not since at some point in
history that previous version was just
fine. It is a document that we do not want to lose. The same for the
software of that time. And I argue
that I do not want to lose the package, either. I am afraid that when we
have it in snapshot.d.o, one or two
releases down the road, the package will be forgotten. We would need
something in our task pages,
then, to point to it, I suggest.