Hello, On 16.12.17 22:15, Andreas Tille wrote:
Hi Afif, On Sat, Dec 16, 2017 at 12:31:28PM -0800, Afif Elghraoui wrote:Since I'm not a user of all this software I do not have any objections. However, I wonder whether we should provide kind of a sensible "migration path" and add "Replaces: tophat" to hisat2 or something like this.Ack. Although I don't believe Replaces: is correct here (looking at Debian policy).Its definitely incorrect.
However, we need to make sure that users who had installed tophat get hisat2 installed.
I disagree.We are packaging software, not workflows (at the very moment, mostly). Anybody requesting tophat shall get exactly that, however unfortunate that decision may be.
I am happy with a post-inst warning, or a debian/NEWS entry, but what the user gets has to be what the user asks for.
The situation is different once we provide workflow packages. Then we will have some NGS workflows that will update tophat underneath as the maintainer of that workflow thinks (and perfectly documents) to best perform the task at hand.
You may suggest hisat2, or even recommend it, but you should not depend on it. And there is no need to enforce a replacement in the first place.Maybe a transitional package is needed, which would have to sit through another stable release cycle. That would also satisfy the concerns about notification time that the others brought up on this thread.After reading this thread I think the better way to go is: 1. tophat Depends hisat2 (solves the issue that the replacement will be installed
2. provide instead of /usr/bin/tophat a shell script issuing
a warning first before the actual tophat call
What about this?
This would undermine the trust that our users have in our packages.Please not. It is better remove the package from the archive than to disturb the integrity of the package.
I propose to discuss any general policy towards such desirable package substitutions at our upcoming Sprint in Barcelona.
Cheers, Steffen