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

[Andreas Tille]

Hi Emilio,

On Fri, Nov 04, 2016 at 09:21:56AM +0100, Emilio Pozuelo Monfort wrote:
> > 
> > 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'.

OK, that's really nasty.
 
> There are two ways to improve this:
> 
> - try not to get these packages auto-removed from testing

Neither sspace nor metaphlan2-data were in testing at all.  These are new
packages that never have made it into testing at all.  So it seems that my
assumption that once the package is in testing (and I fully agree that its
our task to keep them there) no additional force-hint will be required.

> - 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.

I fully agree and you are right we just did so.

When thinking about more solution: Is it really sensible these days to
pin the testing migration on the existence of packages in i386?  I might
be very naive about the mechanism behind but I think at least some
"i386||amd64" logic would be appropriate.
 
> > 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.

Nice we agree upon this. :-)

Kind regards and thanks again for the explanation

     Andreas.

-- 
http://fam-tille.de