Todo tagging and new tag proposals

Justin B Rye jbr at edlug.org.uk
Mon Aug 6 11:17:39 UTC 2007


Guillem Jover wrote:
> inetutils-ftp, inetutils-telnet, inetutils-telnetd
> 
>   The page suggests
> 
>     «There is a 91.5% chance that a x11::* tag is missing»
> 
>   although all those programs are terminal based. Maybe some of the
>   current tags are wrong and are triggering this.

If you temporarily remove the suite::gnu tag this recommendation
goes away.  It must be all those gnustep/windowmaker apps.

> gnumach-dbg - use::TODO
> 
>   What about a new use::debugging? Even though I assigned
>   devel::debugger due to the in-kernel debugger, and not due to
>   the additional debugging symbols.

I'm not keen on duplicating all the specialist facets into use::.
There's a new role::debug-symbols for -dbg packages, and a
devel::debugger to cover the tools that actually do the debugging;
when would a user search on use::debugging instead of one or both of
those? 

> gnumach-dev - devel::TODO
> 
>   This package contains only header files and interface definitions
>   for the gnumach kernel, and the page is suggesting to add
>   devel::libraru which does not seem appropriate. Probably the problem
>   stems from role::devel-lib which is not enterely accurate. So either
>   a new devel::headers or refining role::devel-lib?

Well, I know the definition for role::devel-lib that I'm using:
software used as a build-time rather than run-time dependency.
That definition fits headers well enough.  Most packages full of
headers are called libfoo-dev anyway...

> libaio-dev, libaio1, libglide2, libglide2-dev, libglide3,
> libglide3-dev, openhackware - implemented-in::TODO
> 
>   Those would need something like implemented-in::assembler or
>   implemented-in::asm.

Sounds plausible.  Yes, I see the .asm files in the glide source
tarball... but if there's assembler in libaio then I'm not
recognising it when I look at it, so what am I missing?

> libufs2 - works-with::TODO
> 
>   This would need something like works-with::filesystem.

Possible, but we've got an admin::filesystem...

I would also argue that "filesystem" is an unfortunately vague word.
Ideally it would only cover things like NFS and fuse, not underlying
diskformats (LVM, RAID etc are admin::configuring hardware::storage)
and not directory-hierarchies full of stuff (cruft, gamin etc are
works-with::file). 

Of course, with a good long description this shouldn't be a problem.
-- 
JBR
Ankh kak! (Ancient Egyptian blessing)



More information about the Debtags-devel mailing list