1 |
On Mon, 2009-02-02 at 23:10 +0100, Maciej Mrozowski wrote: |
2 |
> On Monday 02 of February 2009 22:15:53 Luca Barbato wrote: |
3 |
> |
4 |
> > not sure how useful could be but could make more sense even if right now |
5 |
> > kde-base contains everything comes from the main kde distribution. |
6 |
> |
7 |
> To be more specific, kde-base contains everything (and only) that is |
8 |
> distributed as KDE stable release (no extragear included). And it causes |
9 |
> confusion as when packages are dropped from KDE release schedule (so they |
10 |
> usually go back to extragear to release when they want), one needs to look to |
11 |
> new place for them (in kde-misc or somewhere else). |
12 |
> Actually categories are bad idea imho. |
13 |
> I was thinking, maybe it would be possible to drop categories completely in |
14 |
> the future (maybe keeping symlinks for compatibility and to ease migration) |
15 |
> and to put *all* packages in one directory - that would require making all |
16 |
> names unique of course. |
17 |
> "Categorization" could be provided for user/search tools as tag clouds being |
18 |
> defined in metadata.xml as vector of tag:weight values where tag would be some |
19 |
> word from defined dictionary (word like "mail" "client" "kde" "dns" or sth) |
20 |
> and weight - real value [0,1] defining how relevant is that tag. |
21 |
> For compatibility's sake symlinks could be provided, in.ex. sys-devel/gcc -> |
22 |
> all/gcc. |
23 |
> But that's just an off-topic. |
24 |
|
25 |
|
26 |
I agree that a tag kind of approach would be nice. Someone should |
27 |
actually do work on it. |
28 |
Here's a random similar idea that I think might work well as a GLEP |
29 |
proposition, that I was about to reply to a different subthread before |
30 |
noticing this post: |
31 |
|
32 |
Packages metadata.xml can be extended with an unlimited amount of <tag> |
33 |
elements, whose #text can be a tag string, but one that is limited to a |
34 |
given list in some other place - to have a list of existing tags and not |
35 |
just randomly have tags for everything. Make an effort to populate all |
36 |
packages with sensible tags. Then write tools around it that can show |
37 |
you all packages with a given tag or tags, what tags exist, etc. Those |
38 |
will be your new categories that answer the question of "what mail |
39 |
clients are there" (mail-client tag) or "what mail clients are there |
40 |
using GTK+, well suited for a GNOME environment" (mail-client and gnome |
41 |
tags). |
42 |
Keep categories in place for repository tree sanity (not a huge amount |
43 |
of directories with all packages being sibling dirs) and easier |
44 |
implementation of it all. No-one really types in the categories anyway, |
45 |
and with a tool that deals with the tags, you don't look at the subdirs |
46 |
either - so categories for the user just become a way to differentiate |
47 |
packages with the same name for the few cases there are equal names. |
48 |
However those that prefer the categories approach, can keep using it. |
49 |
Developers also deal with categories, but that's easy enough to keep |
50 |
going as is. |
51 |
Less radical, less controversial, better viability to actually get done. |
52 |
|
53 |
|
54 |
-- |
55 |
Mart Raudsepp |
56 |
Gentoo Developer |
57 |
Mail: leio@g.o |
58 |
Weblog: http://planet.gentoo.org/developers/leio |