[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Neurodebian tasks (and Debian Science)



Yaroslav Halchenko <debian@onerussian.com> writes:
> Would any user ever want that particular selection of Recommended 
> packages?   may be, but I see that most often users would want a 
> particular selection from those pointed by Suggests and Recommends.

I think that both is useful. Sure, there are many users who want to have
a detailed list of choices and do an educated selection.

However, there are also reasons for a "simple" way: if one has no glue
where to start with, for example. Or if one has no time (or doesn't
spend it on a carefule package selection). Since today disk space is
cheap, I also tend to just install everything I *could* need -- as long
as there are not conflicts to expect (and Debian is pretty good with
this).

> Are you aiming to provide that level of granularity within debian 
> installer?  if so -- that would be cool.

Sure, I am also unstatisfied with the current state. There is currently
no way to select individual packages during the installation and also
not with tasksel, and I would guess that this will stay so for Debian
Stretch. However, once we have our "foot in the door" (that's probably a
"False Friend" in english), we have a good reason and pressure to get
something. We just need volunteers ;-)

But let's be pragmatic here. The proposed solution is not ideal, but it
is a step forward, and something realistic.

>> Wouldn't it make sense to move out the specific tasks (...) into
>> the "neurodebian" package (and remove it from debian-science)?
> 
> Do you consider neuroscience not a science? ;)  Or is debian-science 
> blend is solely to collect all other sciences which haven't 
> found/established their own blends? and as soon as they do, new 
> naming/packages arrive etc...

I see Debian Science as a kind of "umbrella" for

* blends that are connected to science.
* science tasks that still didn't find an own blend

So, my ideal structure of Debian science would be:

Debian Science
 +-- Debian Astro
 |       +-- Astrononomy Catalogs
 |       +-- Data Viewers
 |       :   ... packges specific to astronomy
 |
 +-- Debian Med
 |       :   ... packages specific to medicine
 |
 : ... other science blends
 |
 +-- Biology
 +-- Physics
 : ... other science tasks that are not in a specific blend

This would IMO also be the ideal structure to show in tasksel (which
does not work yet since tasksel allows only one level structure yet)

So, yes: if there is a new blend, it is time to sort out the
corresponding tasks, rename them etc. I did this when I created the
Debian Astro Blend: the two "traditional" debian-science tasks
"astronomy" and "astronomy-dev" are now moved to debian-astro, and split
of into a much finer granulated structure. There are just two
transitional packages left in debian-science to move existing
installations to the new structure.

> moreover many of those are not neuro- specific, and some times even 
> though used in neuro-, they might be used in other sciences (e.g. 
> consider electrophysiology -- it is not just neuroelectrophysiology)

In the moment (when looking into the package list)
science-electrophysiology *is* neuroelectrophysiology, so I would
propose to have it there.

This is also a question of maintenance; debian-science tasks tend to be
left alone in some cases. science-neuroscience-congnitive seems to be a
candidate for an orphaned task... I would rather love a maintained
neurodebian task than an unmaintained science task.

> that somewhat points to our "concern" with current approach on blends
> -- pretty much attempt to impose separate hierarchies wherever
> structure is more of a tag cloud (single software/task could be a
> part of multiple blends).

In theory this is true; however in the moment we don't have so many
blends that a hierarchy would be unsuitable. There already was some work
by Andreas Tille to cross-link between tasks (@Andreas: could you tell
the state here?), which would improve the situation here, and they are
IMO exceptions: "astro-education" and "edu-astronomy" are such examples.
Most of your "fields" are neuro specific, or don't have a counterpart
that is maintained in the moment.

> I am not sure what such a default blend should carry really... how 
> could I decide for a lab to use e.g. AFNI vs FSL vs [...]

Neurodebian already offers a bootable image, and a default virtual
machine -- so you already *have* some idea of a default installation.

Why not just take this?

I see two arguments for the solution with "default" installations:

1. Provide a simple, low-threshold installation that "just works" for
those who like or need this

2. Promote the blend(s). Everyone who installs Debian will see that
there is NeuroDebian (and Debian Astro etc.), and will think whether
this is something he could be interested in.

>> A "neurodebian-tasks" package would be useful as well so that 
>> people could use tasksel to install additonal NeuroDebian tasks (or
>> to remove them if not needed).

Sure. And, once there is some need, maybe we find a solution how a user
can nicely select individual packages for his blend. But we should not
wait until this happens.

> I guess we could indeed establish a neurodebian-tasks package which 
> could may be provide some pre-canned tasks and also one of which
> would include neurodebian package  itself.  But I don't think that
> those tasks would be the tasks as the blends composes them.

In principle, such a neurodebian-tasks package could be created
automatically, since you already have tasks defined (as "fields") for
your web page. Just take these as a start ;-)

> I see pretty much tasks which would be nearly a single package tasks
> pointing to most common neuro- toolkits so a new user could
> immediately recognize familiar/necessary tools to be installed. [...]

Sure, it is your structure :-) I would however not start with the
perfect solution, but with the structure that is already there, and
improve it.

> Sorry if it is all non-constructive and more of a whining ;)

As long as we move forward, that's fine for me ;-)

Best regards

Ole


Reply to: