Maintaining non-med packages in the team only to satisfy dependencies

[Pierre Gruet <pgtdebian@free.fr>]

Dear all,


Lastly I have begun packaging Java software needed as dependencies of
snpeff, that we would need in Debian Med as it is related to genes and
proteins.

I have thus worked on a Java library related to cdf, pdf and random
variates generation: libdistlib-java. It is currently in NEW.
Now I am looking at the packaging of apfloat, a Java software to perform
computations with arbitrary precision. I have just seen it needs another
Java software not yet in Debian, aparapi, allowing to execute Java code
on a GPU.

I am willing to package them, but my question (maybe naive as from a
newcomer) is the following: is it reasonable to do this packaging work
in the team as those software obviously have a scope larger than ours?
Should we offer other teams (for instance, Debian Science for
libdistlib-java) to host the packaging in a way that would be more
formal than only submitting the ITP bug and waiting for reactions?
This would not necessarily mean waiting the other team to do the
packaging, but maybe to put their ID in the Maintainer field of
debian/control if they want.

Of course we in Debian Med will do the maintenance effort as we need
those software (e.g. for snpeff, which we want to have in Debian), but
don't you think that other teams could blame us for working on packages
that would logically be maintained by them?

I imagine you already have an opinion on that, and I would be interested
in the rationale.

Thanks for reading, and have a very nice week-end,
Pierre