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
