debram and debtags

[Erich Schubert]

Hi Thaddeus,

> `ocaml-base' package depends on `xlibs'.  (Why
> does it depend?  I do not know.)

Probably because the base system does include x11 support.
It's not always easy or wanted to split off x11 support into a separate
package. If i try removing xlibs, a couple of weird things would be
removed - cupsys for example. tetex-bin. aalib1.

I used such heuristics for the debian tags database as well, but only in
a couple of cases (mostly deps on -dev packages or interpreters)

> dependencies, making it far easier to find
> packages with modest dependencies when such
> packages are wanted.  (The implication, of

This is inherent to our system, too: A package with less features will
appear higher in the hierarchy, whereas a feature-packed programm will
more likely be in a subgroup.

> dependents together in a fairly natural way.  In
> the case of "xmms-jess", it went to SDL because
> it requires the user to install SDL
> infrastructure, whereas the other XMMS packages
> do not.

xmms-goom does, but i don't know if that is in woody, too.

> I do not deny it.  Wow.  I needed a year and a
> half just to produce the `debram' you see today!
> I am fully willing to admit that I had no time
> to cross-bind the individual packages to several
> branches each.  Can you blame me?

Of course i cannot. I am aware if the amount of work needed to
"cateorize" that many packages. That is why we want to distribute the
workload. If every maintainer has to do it for his own packages that is
an acceptable amount of work.

> above.  A third is that it gives each package a
> single home in the hierarchy and thus prevents
> unfocused, ill-designed, Creeping Featuristic
> packages from calling too much undeserved
> attention to themselves.  A fourth is the

They will disappear into subgroups with debtags, which is a nice
side-effect. But debtags needs carefully balancing of tags, too. :-(
A package with few tags will float up to the top otherwise.

> Sometimes contests are good; sometimes they
> aren't.  In our case, they probably aren't.  How
> would Debian's future users like it, after all,
> if we confronted them with two incompatible
> cataloging schemes?  I doubt that we would have

Yes, doing two classifications would be a waste of time.
My comment wasn't meant as "we have three schemes and can keep them",
but "we have to take the best of each and do it better"

Like Trove probably being the only one with Licence tags yet; our
current structure a (underdeveloped) focus on supported file formats
and such things.

One of the really big points i think we need to tackle is
differentiating the package focus.
That is (/very inconsitently used right now in debtags/) the difference
between:
- applications (i.e. interactive)
- utilities (i.e. command line)
- plugins
- servers
- clients
- daemons (non-interactive local things like logrotation)
- filters
etc. pp. - I find it very hard to make some policy when to call
something an application, when an utility. Servers/daemons is another
difficult thing. Clients are often applications as well...
Actually server/client/standalone is orthogonal to
interactive/called_function/daemon
I find all these things very difficult.

Then there is cli/gui::*/web and this differentiation debtags currently
knows... this overlaps with the application/utility thing as well.

We should try to define proper "axes" of this kind, and require each
package to have at least one tag from these axes.

Another thing i'd very much like to add is the target audience.
We already have a "junior" tag, an "edu" tag and such.
Again there are two approaches: "recommended-for-juniors" and
"not-suiteable-for-juniors"...
But these things probably should be made "addons". (medical, lex,
accessibility, junior, skolelinux... there are so many...)

But "user-skill-required::little" would be an interesting filter...

Greetings,
Erich Schubert
-- 
     erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C     (o_
 A man doesn't know what he knows until he knows what he doesn't know. //\
        Ein Freund ist ein Geschenk, das man sich selbst macht.        V_/_