Hello, On December 17, 2017 8:35:21 PM EST, "Steffen Möller" <steffen_moel...@gmx.de> wrote: >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 understood this proposition as installing both tophat amd hisat2 while also giving a warning whenever running tophat. > >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. Yes. > [...] > >> >>> 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 >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. >> 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 don't think having a warning message disturbs the integrity of the package--we are not changing its functionality. In fact, adding a warning message might even be welcomed upstream. > >I propose to discuss any general policy towards such desirable package >substitutions at our upcoming Sprint in Barcelona. > I won't be there. In any case, this is probably a more general problem than one in bioinformatics, so would probably best be discussed on debian-devel. regards Afif