1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
Enrico Zini suggests the inclusion of the
following post, which reveals some debram
history.
To: Debian usability ML <deb-usability-list@lists.alioth.debian.org>
From: "Thaddeus H. Black" <t@b-tk.org>
Subject: Re: Debtags and Debram (Was: Re: New debtags suite just uploaded)
List-Archive: <http://lists.alioth.debian.org/pipermail/deb-usability-list/>
Date: Fri, 2 Jul 2004 15:29:41 +0000
...
Enrico wrote,
> I'm having a hard time understanding the
> structure of your categorization: I see you're
> using some important background in library
> science that I'm not knowledgeable of, and I'm
> even having trouble understanding the logic in
> which your hierarchy is structured.
I confess that I have no background in library
science.
A bit of debram history may serve to clarify the
situation. The history begins in the potato era
with a rationale: namely that, like you and
everyone else on this list, I couldn't ever find
anything in Debian. It was one giant heap of
four thousand packages. This drove me crazy,
and since neither Ranganathan nor any other
skilled librarian actually seemed to be working
on solving the problem, in March 2002 I started
sorting the packages into piles, then dividing
the piles into smaller piles, then moving the
little piles around subjectively until they
attained an overall pattern that somewhat
followed the traditional Unix man sections and
otherwise made subjective sense to me. Then I
labeled the piles and sorted them some more.
The process was entirely iterative. I suppose
that by now I have attained a better overall
knowledge of the contents of the Debian archive
than all but a very few people in the world, but
I still do not know the first principle of
library theory. I just sort stuff.
Then you debtags guys came along (or maybe you
were there before, but I didn't know it). You
had some great ideas which I had never thought
of. I was working mostly in isolation and, not
yet being on the DD keyring, I thought it best
just to lurk for a while, continuing to work on
the debram. I did not know you, after all.
I had already done a lot of work on the debram.
I did not know if you were serious. How could I
know? Most people who post ideas on lists are
not serious. Tagging the archive is a big
project. I did not want to risk starting
discussions with you if you might just go MIA
six months later.
Well. You guys are still here and I am pleased
to observe that you seem to be 100 percent
serious. This is a relief to me. The big heap
of packages has tripled in size since the potato
days, and it is still a BIG HEAP. This is
surreal. It is also too big for me to handle
alone. I am pleased and relieved to lace up my
boots and join your army.
However, we have a temporary but real problem.
You started by defining tags to assign to
packages. I started by sorting packages into
piles then naming the piles. Your approach is
smarter, but under my approach the work is
nearly done. And the two approaches are
apparently not mixing. In chemical terms, what
we want is some detergent that makes debram
soluble in debtags. We want debram to mix.
> And also, how do you build the hierarchy? How
> do you decide that, for example, Audio is
> under "User oriented packages" but Graphics is
> under X/X Applications/ ?
Good question. Looking at it from the debram's
perspective, can you see how it would happen
this way? I did not design the hierarchy then
sort the packages into it; I sorted the packages
then built the hierarchy around them. From this
perspective, [1800 X] emerges as a natural
division of the archive. The [1900 Audio]
emerges as a natural division, too, but of a
different character because its various contents
have a unifying theme but lack a mutual set of
dependencies. I didn't design it this way; this
is just how Debian has grown up. In general,
the more Maintainers were working on a
particular kind of package or the more
fundamental the kind of package seemed to
general Debian operation, the more prominent a
place that kind of package earned in the tree.
Packages with similar purposes, similar
audiences and/or similar dependencies tend to go
together; but whether the purpose, the audience
or the dependency is the dominant consideration
varies over the hierarchy: sorting
considerations which work well
in [1300 Programming], for example, may not work
so well for [1800 X]. No geometrical precision
is possible in this.
The biggest single problem with the debram is
with some packages which strongly naturally
belong in each of two different branches. For
various reasons, I wanted (and still want) each
package to have a single principal home on the
tree, but for some packages this approach has
created real problems. The problems are
particularly acute within
1580 CJK (Chinese/Japanese/Korean),
1716 SGML / XML,
1720 Mathematics,
8151 Kernel Control and Management of
Central Hardware,
and a few others. The debtags solve this
problem, and do it in a way which does not
fundamentally require us to give up debram's
gains in this area.
...
|
