New tags for biology and medicine.

[Steffen Moeller]

On Wednesday 05 September 2007 09:40:19 you wrote:
> On Wed, 5 Sep 2007, Steffen Moeller wrote:

> > As a DD and knowing me to use your packages you can do many things :o)
> Sure.  But in this case a clear tracking path is implemented and I can
> do this only with an upload of a signed package.  Changing Debtags is
> open for anybody without a login.
Ah, right. This would be a problem of authenticating the assignment of debtags 
to packages. To have "everybody" doing this would indeed be a problem for my 
use case. But for now we are discussing how to come up with a sensible list 
of debtags. The assignment of tags to packages will certainly evolve, too, 
and happen outside of Debian for many user groups.

> BTW, IMHO the best way to install a cluster is using FAI.  An alternative
> might be FAI or you can use FAI if you want to avoid the first two. 
RIght, FAI will be a mechanism to install software. The decision on what 
softare should be installed is done elsewhere. This is a separate issue from 
Debtags in my current understanding.

> All 
> three alternatives are working perfectly fine and are completely ignoring
> DebTags (to my knowledge).
Ah. Right. 

> So I see no reason at all to rape DebTags 
> technique for things it is not really made for.
Ahem. Interesting dialectics here. To me DebTags are a way to describe 
software packages. A main motivation to have these tags, if I recall 
correctly, is to filter packages when presenting them to users to make them 
select software for local installations. This reduces complexity and we all 
like it. My suggestion is to use the very same filtering for the question if 
a particular software may be installed by someone of a third party who you 
basically trust but do not want to give full freedom. Let us assume that the 
assignment of tags is performed by some instance that you fully trust. I 
really cannot see any harrassment of principles behind DebTags here. In the 
very contrary.

> > But, yes, an authority that assigns tags to software packages (the
> > authority could be in Debian or in some grid community) will have some
> > influence on what software is eligible on some cluster's specification.
>
> ... which would be definitely a no go for clusters that would be under
> my personal control.

This is fine. I personally however do not see much of a difference between 
someone shares the administration of a cluster with a second person, being 
employed by the same institution and a szenario where 5 sysadmins are 
employed to maintain 10 clusters, each paid/earmarked for different tasks. 
The latter use case is that of some university's campus grid or larger 
scientific or industrial institutions with multiple outstations.

>
> > Exactly. Think of
> > these installations as transient dynamic events that are associated with
> > jobs seeking a cluster on the grid for its execution. For some clusters
> > in the grid a software will be allowed to be installed on demand (because
> > of the debtags assignments to the software and constraints imposed by the
> > cluster) and on others not.
>
> Well, you mentioned that you want to do this but I have never seen giving
> you any reason for this or any advantage you want to gain by using this.

The advantage is the adaption to complex workflows. I see no way that system 
administrators can prepare all tools well in advance and all database and 
update them all in time. No way, even for some constrained field like 
biological sequence analysis. Maybe the admins get in sync for the first 
users and agree on some setup, they will not do it for the 205th. And they 
should not. So if you need a tailored runtime environment for your tasks, 
then you need some way to get it established dynamically.  Now, every cluster 
participating in a, e.g., campus grid can allow arbitrary installations or 
they could be constrained differently for each cluster. DebTags would appear 
like a very reasonable language to constrain and describe packages.

> >> Well, probably we could convince DebTags people by just naming the
> >> 5+x entries that a catagorie makes sense without having an extra
> >> repository.
> >
> > Fine. But we need a way for us to assign the packages then to tags that
> > are not yet part of debtags. Or am I mixing things up here?
>
> No you are right.  At first there must be a tag and then you can assign
> it to the package.  My suggestion was rather this way: Write a kind
> e-mail to debtags-devel and tell them: We have package p1, ... , pn that
> would perfectly fit into a new category named X.  Please add this
> category because ... (some reasons).  I guess with this approach we
> sound much more convincing than just proposing categories that are
> very specific and the people who are not working in this field are
> not able to understand the real need.
This has something of a hen-and-egg problem. We have this file here:
http://svn.debian.org/wsvn/debian-med/trunk/community/debtags/tags?op=file&rev=0&sc=0
which features many facets, badly lacking descriptions, still. We could come 
up with an extension of that format (or it may be existing already) that also 
assigns the affected packages for each term. With a certain number of 
assignments we would ask for their adoption by debtags. Would this sound 
reasonable? The subversion page would help us not to forget about ideas and 
at least to me it is also fun.

Many greetings

Steffen



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20070905/3ff46151/attachment.pgp