Hello all, I have been trying to tag those of my installed packages which are either untagged or tagged incorrectly. It's been great fun. In the process, a number of questions arose.
The DebTagsFacets Page Is DebTagsFacets on wiki.debian.org the right place to look for the meaning of each facet? I found it very helpful, but http://wiki.debian.org/DebTags did not provide a strong "information scent" for it. At first, I thought it was going to be a page on the concept of faceted classification and so I skipped over it completely. The works-with Facet How is the works-with facet meant to be used? I understand that if a program groks some format as input, then a works-with-format::that-format tag is warranted. If a program is used to read image files, then we put works-with::image. But how would you tag a program that converts text files to image files? Would this be "use::converting, works-with::text", "use::converting, works-with::text, works-with::image, works-with-format::image:jpeg", or something else? What about a program that does not work directly with an object but makes use of it indirectly by means of another program? For example, pristine-tar does not directly work with git repositories, but its very purpose involves maintaining a branch in a git repository containing the information needed to reconstruct published release tarballs. It does this by invoking git. Should pristine-tar have a works-with::rcs tag? (Such a works-with tag for source control does not currently exist, but from the presence of works-with::db I infer that it probably should.) Documentation packages and the use facet How are documentation packages meant to be tagged? (I know this question is addressed on the DebTaggingGuidelines wiki page, but I did not understand the answer.) On the DebTaggingGuidelines page, it is implied that if a libgetopt-doc package existed, it would have to include an interface::commandline tag because it is helpful in creating commandline interfaces. This seems wrong to me, because interface:: is a facet of a package's personality (meaning interface), but in this use it would be describing energy (purpose). I think I understand the idea: the point is that if a package has role::documentation, then it is impossible that the package itself provides a program with a commandline interface; so it is most useful, or so the logic goes, to reuse these tags for another purpose. Well, that's crazy, in my not so humble opinion. Let me backtrack and say that for use:: and other facets of energy, maybe that logic would be almost appropriate. An idea I could almost be persuaded to agree with would be as follows: Suppose that package foo is really meant for fooing, but that after some contortions, by combining it with other scripts or by carefully interfering with its operation, we can make use of it for bazzing. Suppose that the foo-doc package explains how to use foo to baz. Then, one could argue, package foo should have use::fooing and not have use::bazzing, and package foo-doc ought to have use::bazzing. This is such a rare situation as to not warrant its own rule, I think. Also, it would be very hard to tell in a given situation whether the rule applies, and if a rule is not straightforward to apply in each case then it is likely to end up being applied inconsistently so that for our purposes it would be useless. So even though I could almost be persuaded to adopt this idea, I am not persuaded yet. To summarize: I think documentation packages should not have any tags in the use:: facet at all, except for use::configuring if they include sample configuration files, use:: tags reflecting the use of included example scripts, and use::learning if they are especially helpful to those unfamiliar with some subject (maybe). Similarly, unless included scripts, sample code, or pen-and-paper game instructions warrant it, documentation packages should not include tags under the accessibility, admin, devel, game, hardware, office, security, sound, works-with, or works-with-format facets, except for devel::doc. This goes against some existing practice of putting use::browsing, works-with-format::pdf, etc. for documentation. Documentation should instead have role::documentation and made-of::data:pdf, etc. Am I interpreting the tags correctly here? The scope facet I was unable to figure out what tags for the scope facet, if any, packages should get. The DebTaggingGuidelines wiki page says in its description of scope::application that scope::application should be used for user-friendly programs and scope::utility should be used for programs that might be run in a pipeline. In its description of scope::utility, it says that scope::utility should be used for non-interactive programs. The current vocabulary file says that scope::application should be used for programs that do that 80% of the things you want to do 80% of the time towards a particular task (i.e., programs that feel somewhat complete in themselves --- see <http://www.mozilla.org/unity-of-interface.html> for this idea taken to an extreme), while scope::utility should be used for more marginal programs that do more marginal things (but when you need them, you need them...). So here are three distinct ideas of what scope:: means, and all of them are vague. I don't have any real thoughts on which one is most useful, except that you can tell an interactive program by its interface:: tags already. I just mention it because it left me confused. Apologies for sending such a long message. I have still more questions, but I think these are enough for now. Thanks in advance for your help, Jonathan Nieder _______________________________________________ Debtags-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debtags-devel
