Re: removing tophat from Debian
Hello,
On December 17, 2017 8:35:21 PM EST, "Steffen Möller" <steffen_moeller@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
Reply to: