Todo tagging and new tag proposals

[Guillem Jover]

[ Sorry for the delay, I'm not subscribed and failed to ask to be CCed,
  please do so next time. ]

Hi,

On Mon, 2007-08-06 at 12:17:39 +0100, Justin B Rye wrote:
> 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.

Hmm ok I'll ignore it, although it's a bit annoying. ;)

> > 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? 

Ok, just added role::debug-symbols, I didn't see that one when
tagging, not sure if it existed then.

> > 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.

Sure, but the page complains about a missing devel::library which I
think is wrong and is what triggered my initial comment, because the
package does not provide any library at all.

I just tagged it devel::rpc (but it still complains about the missing
tag), which is what the package is providing, the headers are used by
the programs to call the RPC stubs which are generated at build time by
an interface generator from the interface definitions (also provided on
the gnumach-dev package).

> Most packages full of headers are called libfoo-dev anyway...

That's because they are part of a library. But not all headers are
part of libraries.

> > 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?

The asm in libaio is inlined in the C source code (specifically in the
headers), the important thing to me is that because it has asm it
makes the package archiecture dependent. Having such tag would make it
really easy to spot packages with possible portability issues.

> > libufs2 - works-with::TODO
> > 
> >   This would need something like works-with::filesystem.
> 
> Possible, but we've got an admin::filesystem...

Yep, that's the one I've used for ufsutils, which is the package
containing the tools to operate on the filesystem. But is the library
who directly manipulates the data contained in the 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). 

Right, although I don't find the word vague, but YMMV.

> Of course, with a good long description this shouldn't be a problem.

Sure.

thanks,
guillem