[Debian-med-packaging] Please add force hint to enable metaphlan2-data testing migration

[Emilio Pozuelo Monfort]

On 04/11/16 08:43, Andreas Tille wrote:
> Hi Emilio,
> 
> On Fri, Nov 04, 2016 at 12:31:41AM +0100, Emilio Pozuelo Monfort wrote:
>> On 02/11/16 16:49, Andreas Tille wrote:
>>> Hi release team,
>>>
>>> meanwhile the revision of the package metaphlan2-data has increased
>>> so please add the force-hint to this package:
>>>
>>>      metaphlan2-data 2.6.0+ds-2
>>>
>>> BTW, I wonder what the to be expected time scale would be when these
>>> force-hint requests are dealt with.  There is another one from Debian
>>> Med team pending for sspace.  The testing migration of these both
>>> packages would help a lot.
>>
>> You're asking for a pretty big hammer, which we don't like to use.
> 
> Hmmm, I'm afraid I do not understand what you mean.  What exactly is the
> big hammer and how can I prevent asking you to use it?

The big hammer is a force-hint type hint, which basically tells britney 'ignore
everything with this package and migrate it to testing, no matter what'.

There are two ways to improve this:

- try not to get these packages auto-removed from testing
- make bowtie/bowtie2 32-bit friendly

I imagine the latter is a difficult task or it would have happened already. But
it would be the right solution to this problem, and a good outcome for bowtie
and its rdeps as well imho.

>> It doesn't
>> help that you got some of these packages removed from testing, and everytime
>> that happens you need to come and ask for this again...
> 
> I probably have a totally wrong information that if a package of
> architecture all that depends from packages not available for i386 does
> not migrate to testing without a __single__ force-hint from release
> team.  I would really love to spare you manual work which seems like a
> big effort (=pretty big hammer) for you.  The only option I know would
> be to wrongly declare the package as Architecture: amd64 which has the
> pretty same effect since the dependency bowtie2 only exists for amd64
> but its simply wrong and would most probably have a bad side effect for
> autobuilders.  I'd be really happy about any advise what might be the
> better way from your perspective.

Yes, that's a bad workaround indeed. No need for that.

Cheers,
Emilio