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
Description: This is a digitally signed message part.