> > Well, I thought of this, yes. But there are times when a program uses > > more than one language. For example, Oregano (an electronics program > > that I help maintain) is coded in C, uses a lot of GTK, but also has > > some perl scripts... So, if a bug occured in a perl script, it would > > show up as a C+GTK bug, which it is not...
> Nice example of a corner case but what are these perl scripts doing ? Does it matter? The program uses them to convert from one simulator format to the other, or something like that. > It's mainly a gtk+ program - as it's already tagged, but lacks > made-of::lang:c atm. Well, yes, it's in my TODO list to correctly tag all of my packages. > If you think about it more deeper, what if a random package contain a > buggy postinst, prerm, ... but the software itself is written in > language x ? The tag won't be useful to prepare a report containing > "language x bugs", but "bugs into packages made of language x" imo. Yes, indeed. That's why I don't want to rely _only_ on debtags. There could be a lang-pkg-debian, or similar, because that's the skill needed, even if the script is written in bash, you need to know more than how to use the shell to do a correct postinst script. Or maybe, we could make the language tag be bash, and have another subgroup of tags named "skill" which might include things like ui, pkg-debian, complex maths, etc... It might be nice to have that too, although it might also be more difficult to assess which skills are necessary. -- Besos, Marga
