Re: [RFC] New task: science-dataacquisition
Andreas Tille <tillea@rki.de> writes:
> [Move this thread to debian-custom list because it belongs here instead of
> debian-science list.]
>
> On Thu, 11 Dec 2008, Chris Walker wrote:
>
> >> The fact that until now nobody has sended me a patch
> >> to blends-dev in my eyes is a prove that there is nobody out there who
> >> regards a deeper structure in metapackages as important enough to spend
> >> some time on it.
> >
> > I've not yes found the time to do this - but one of these days...
>
> Sounds like a new years intention. ;-)
:-). We'll see what I get around to.
[short versions]
>
> Done.
Excellent.
>
> > If you did that, and also provided a means of having subsections - by
> > not sorting the packages at all (currently they are alphabetical), and
> > having the ability to put in subheadings - not sure of an appropriate
> > syntax, but something along the lines of:
[snip]
>
> ... "If you ... provided a means"
> Well, IMHO we are stretching the debian-science list to far for this topic.
> It is not me - it is a Debian Pure Blends effort. We should move the
> discussion to this place. The current state is:
>
> The tasks files contain per definition an _unordered_ _list_ of
> dependencies. (OK, med-bio has some *unmaintained* structure hidden
> in "Why:"-tagged comments.) Having an _unordered_ _list_ published
> on the web pages just sucks - so the only automatic means for an
> ordering is alphabethical.
>
> What you want is:
>
> Proposing a Section marker field that enables a parsing program to
> detect sections (or even subsections). Document the field in the
> Blends documentation. BTW, RFC822 format actually does not really
> support this sectioning. It is a flat file format with paragraphs.
> Each paragraph ends with a blank line. A section field which should
> be valid for more than one paragraph entry is in principle a hackish
> solution. I do not say that this is a real problem - but I would
> like you to be aware about this. (I wonder whether I should tell
> that XML would be the proper solution for your suggestion because
> there were enough XML versus RFC822 flame wars - at least you will
> have a hard time to convince me to change a running system. I guess
> working patches would be convincing but probably no e-mails without
> patches.)
One alternative that comes to mind (and I don't know if it is better
or not) is to put the structure in subdirectories (and perhaps that is
what you are telling me by suggesting a physics blend).
>
> Once you have ironed out your proposal on the mailing list and in
> the documentation start inserting these section fields in at least
> 50% of the existing tasks files.
>
> Once this work is done I see that there is at least one person who
> regards the problem as important enough to push me for an implementation
> of this feature.
>
> Please don't get me wrong: I do not say that your suggestion is bad.
> In principle I like it. It has the side effect that the web pages
> become even more important than metapackages (because they will not
> reflect this new feature). This is OK, because the web pages are
> even visible for the whole non-Debian world.
Indeed. I think that debtags are probably the ultimate solution for
the Debian world - but haven't worked out quite how to apply them.
One flaw with the metapackages approach is that they you end up
installing several packages to do the same thing. I don't think you
really want this - why install 3 packages to grab data from scanned
graphs - after some initial testing, you'll only ever use one. It
might be possible to use ORed packages, though this perhaps makes it
more difficult to say to your sysadmin "install the physics task and
I'll have everything I need".
> But you are simply
> competing with for instance a lot of GNUmed users who desperately are
> waiting for a GNUmed server package, other Debian Med users are waiting
> for updated packages in the field of imaging (BioImageSuite is not
> even tackled by a Debian maintainer). So you have to compete with
> the wishlist bugs of other users and convince me that your wishlist
> is more important than theirs.
Indeed.
>
> >> Maintaining a "competing" Wiki page is doing manual work for less
> >> information with the constant danger of beeing outdated for the
> >> small advantage of slightly more flexibility in the content and
> >> having the chance (but not the real effect) to involce more people.
> >
> > It is the extra structure that I think is useful. I've been organising
> > the wiki as a prototype structure useful until someone gets around to
> > adding this facility to the tasks files.
>
> As I said this was well done and the job you did was really important.
> What I further said is: The time is ripe for this "someone" to start
> with the tasks files *now*.
For physics, in the immediate future, I plan to stop explicitly
listing packages in the data acquisition and numerical computation
tasks, and replace them with a link to the task. I shall probably do
the same with image analysis too.
The question is whether to do any more splitting. I could split
particle physics into a seperate task - but the most any of the other
subsections contain is 3 packages - and to avoid hiding packages too
deep in menus, neither of us want that lefel of granularity.
>
> > [1] At this point, I'm going to keep very quiet about the fact that I've
> > been trying to maintain the physics task too :-).
>
> ;-)
>
Chris
Reply to: