debian package browser

[Hervé Eychenne]

On Fri, Jan 30, 2004 at 04:15:08PM +0100, Erich Schubert wrote:

> Hi,

> > I see what you mean... Why not. I suppose that unfolded tags would be
> > tags where a tag named x is associated to x::{a,b,...}. That can be
> > done automatically.

> Kind of. We usually don't want it. There are just a couple of cases.
> If you look at the vocabulary in alioth cvs you should be able to spot
> them easily - just check "ui".  For example "ids" shouldn't appear as a
> sub-choice of "security" as soon as a security subgroup is formed.

> The proper way to store this information is another issue. OTFH it is
> part of the vocabulary, OTOH it is tag-browser-dependant information.
> I'd like to be able to change it without updating the browser package...

> > Then, if ui was an "unfolded" tagname, I guess no
> > package should have ui as a tag, but ui::* instead.

> It's way easier to calculate if every package which has ui::* is
> required to have "ui", and every "ui" package at least one "ui::*" tag.
> Of course you can strip these "implicated" tags from the packages.gz
> file, but that is just reducing the file size.

By the way, noone did respond to my post ("adding some tags") where I
asked where (and what) are the _real_ database...

I don't care about the packages.gz, as I guess it is only a generated
file... All it has to be is as small as possible (even if compressed).

But I don't like to introduce redundancy in databases, even for the
sake of efficiency. And that's exactly what you propose here. I'm
all the more against it as the database is a little one (here), and we
have absolutely no performance issues.

> FYI: i don't think "mail" is that hard to find, although the packages
> are tagged _really_ bad. (most don't have protocol tags etc.)

> Network and Communication, Network Client, Email
> and then look in "User Interface", too.

Yes, I know.

> Unfortunately, mutt doesn't have user interface tags, mozilla-mailnews
> is not tagged "client" and so on. See: that is the real problem -
> inconsistent tagging.

Ok, I see. So let's say that considering the fact that the tag
database will never be perfect, my approach is a little more reliable than
yours. ;-)

 Hervé

-- 
 _
(°=  Hervé Eychenne
//)  Homepage:          http://www.eychenne.org/
v_/_ WallFire project:  http://www.wallfire.org/