[Neurodebian-devel] How can Blends techniques be adapted to NeuroDebian

Andreas Tille andreas at an3as.eu
Sat Jul 21 22:10:04 UTC 2012


Hi,

at Debian Science Workshop I had some discussion with Michael Hanke
about how Blends techniques can better support the needs of NeuroDebian.

At first I would like to present my *personal* view on NeuroDebian:  The
topic itself in my eyes perfectly qualifies as a Blend and there is an
existing team which does an amazing job in advertising Debian in the
field of neuro science (exactly what a Blend is about).  On the other
hand NeuroDebian is not using the Blends techniques itself but rather is
cherry picking from some Debian Med and Debian Science stuff.

Recent developments like the new handling of citations and the usage of
VCS information made this cherry-picking process harder and there is
some need to find new ways for propagating the data.  In the discussion
in Grenoble Michael told me that it would be sufficient if in the
process of creating the tasks pages some RST files featuring the
information about packages would be created.  When trying to do so I
realised that while it is possible it is technically not a really good
solution because the used technique (Genshi) usually works with XML and
not just plain text.  It would be possible to circumvent this by
exporting HTML and piping this through `lynx -dump`.  Michael also
suggested to alternatively export some XML the NeuroDebian team could
deal with as well.

In an unrelated discussion[1] Michael suggested some alternative way to
handle tasks and I explained why I personally do not consider this a
good idea.  My suspicion that the handling of the package grouping in
NeuroDebian is organised suboptimal is when I have noticed by chance a
debian/blends file in some not yet finished package which was basically
copying information from a Debian Med task file which is no removed.

All three facts (NeuroDebian qualifies as Blend, cherry picking from
Blends stuff is ineffective and it will finally not work any more) seem
to indicate that we should probably try some other approach.  My
suggestion would be that NeuroDebian would actually start using tasks as
other Blends.  I'm aware that inside NeuroDebian some more interesting
stuff was invented which is not available in the usual Blends
techniques.  On the other hand the development inside NeuroDebian sounds
quite interesting for other Blends as well - from my perspective a
perfect situation to join forces and implement the needed things for
every Blend on the basis of the Blends sources of information.

In any case it would help drastically if the NeuroDebian team would be a
bit more verbose about what is need (I somehow learned by chance that my
plan to reduce redundant information from the tasks files would spoil
NeuroDebians way to obtain data) and what should be approached.

Kind regards

     Andreas.


[1] http://lists.debian.org/debian-med/2012/07/msg00220.html

-- 
http://fam-tille.de



More information about the Neurodebian-devel mailing list