[Debtags-devel] Updating tags on svn

[Justin B Rye]

>>>>  Most packages will get no more than one of the four tags
>>>>  role::sw:{utility,daemon,application,amusement}.
>> 
>> Maybe this is less ambiguous:
>> # Packages will not usually get multiple tags out of the set
>> # role::sw:{utility,daemon,application,amusement}.
> 
> Unfortunately I do not understand this conversation.  Sorry.  Feel free
> to clarify.

In principle the first version could mean that most packages will
get no tags under other facets, or that no packages will get role::
tags other than these four.  Or readers might realise that these
interpretations are unlikely, but be confused into guessing a
meaning it doesn't strictly support, such as that sw:server tags are
forbidden on sw:daemon packages.

(From here on, remember it's all issues I wouldn't have bothered to
raise if I hadn't already been writing!) 

>> There are places where the definitions seem to be describing
>> binaries instead of packages,
> 
> In Debian terms, I assume that you mean "executables instead of
> packages."  If so, you're right.  I couldn't find a more elegant way to
> write it.  One could lengthen "as find" to "as the find executable," but
> like Goethe, Churchill and Hemingway, we should save the excess words, I
> think.

Only a couple were cases where there was any question of the name
being misleading:
* mozilla - "mozilla-browser" is the one with the application in it.
* perl - it's "perl-base".
So forget those.  What I'm really thinking of is the more nebulous
danger that by starting from individual executables you'll overlook
the way they work together:
* latex - is in tetex-bin, along with a great many utilities,
	several of which are not much smaller.  Is the package
	really "an application"? 
* autotools - actually I'm not sure either what executable or what
	package you were thinking of here, but are you quite sure it
	isn't a toolchain of utilities?

>> # Configuration         
>> # scripts (as the kernel's) whose only normal mode is a series of    
>> # questions and answers
>
> The other example which comes to mind is the obsolete xf86config.
> However, this is not a package in itself; so, no, I cannot give the
> example you seek.  (If a better example occurs to you, let me know.)

There's still an "xdebconfigurator" package, though I don't know how
it compares to "dpkg-reconfigure xserver-xfree86".

> The reason I wrote those words was to support Erich's useful criterion
> that a utility is something used in a processing chain.  Taken alone,
> the words say nothing very important, but in the context they clarify
> the point that mere crudity does not make a program a utility.

They aren't clarifying it for me, because I'm only guessing what the
hypothetical Q&A package would be like - if it's like "make gconfig"
with an added "load tarball" menu-option and a progress bar, then
I'd certainly see that package as an application, but if you can run 
"yes | linuxconfigurator", that's another story.
-- 
JBR
Ankh kak! (Ancient Egyptian blessing)