Creation of new task Bio-NGS
Hi,
when sitting at Debian Med Sprint in Travemünde the question was rised
how one can install all Next Generation Sequencing packages in one rush
(and nothing else). This nothing else part made the answer "Simply
install med-bio" the wrong choice and thus I found another answer to
create a new task which exactly fits this question: Create a bio-ngs
task which does exactly what this user wanted.
To turn this from a quick hack into an acceptable solution I'd like to
discuss here on this list - newcomers hanging around at the sprint and
are happy with this solution are explicitely invited to devend this
solution.
While the hack (for the moment it is) has some pragmatic use we need to
rethink the granularity of the Bio task again. Just splitting out one
part does not solve the problem. I'm also not yet convinced that the
former action in this line the Cloud task which somehow was of a similar
intend (just find a quick solution for a certain problem and extract
all non-GUI packages in a separate (but additional) package) is a non
optimal solution. But having two non-optimal hacks should be reason
enough to make things more straigt.
Tha fact that NGS packages were now in a separate task should IMHO have
the consequence that these packages are not in Bio any more. To find
those packages easily we should rather make the med-bio package depend
from med-bio-ngs to poll those dependencies. While this will work it is
another hack which silently introduces a kind of hierarchie into the
Blends framework which it is not designed for.
So what options doe we have?
1. Simple and dirty "solution":
Just leave it as it currently is and even add more bio-xyz
tasks.
2. Missuse the Blends framework and fake a hierarchy
Turn Bio into a meta-metapackage sitting on top of several bio-xyz
tasks. If this way should be choosen we need to decide whether
some real non metapackage dependencies should remain or if we go
with some bio-other which will not fit into the bio-* categories.
If you suggest this solution please be prepeared for suggesting
reasonabe categories to split up Bio
3. The hard split
From time to time people consider splitting up Health Care and
Biological applications: A new Blend would be a new hierarchy and
thus is the proper use of the Blends framework: Handle a new
hierarchy tree in a new Blend.
I'm quite unsure what is the proper solution here. WHen this idea was
rised the first time I recieved a very angry email from a biologist who
tried to forbid me to cover the Biology field in Debian Med because it
is not Medicine. Well, forbidding does not work in Free Software but
doing some work is always helpfull: So my answer to this guy was: I'm
fine if you just do the biological part and I wish you good luck to do
so. I have never heard again from this guy ...
However, I did not really wanted to make fun of him and the request is
perfectly valid. Just now some of the sprint members mentioned that he
never realised that Debian Med is for him (as a biologist) because the
term biology is missing in the project name. Locking back for eight
years of life time of Debian Med I think merging these fields was right
at the point in time when we started because we were a small number of
developers. Currently I would not see any problem to have a critical
mass to run separate Blends. I would keep on working in both fields
because I'm interested in both. I'm positive that we have several
competent people who will continue working in each field not to mention
those people who might give fresh blood into Debian Med after this
sprint.
But please do not interpret these words as a perference from my side for
this split solution. I consider all three solutions as ways to go - each
has pros and cons. If you add your own pros to the way you would prefer
please make sure to mention what point is making you think this is the
best way and in how far you personally want to support this way.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: