1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Brian Harring wrote: |
5 |
> On Wed, May 11, 2005 at 06:01:17PM +0900, Georgi Georgiev wrote: |
6 |
> |
7 |
>>maillog: 11/05/2005-03:40:04(-0500): Brian Harring types |
8 |
>> |
9 |
>>>>On Wed, May 11, 2005 at 09:46:03AM +0200, Kevin F. Quinn wrote: |
10 |
>>>>Here's my suggestion, for what it's worth :) |
11 |
>>>> |
12 |
>>>>The layout on disk and the semantics of categories do not need to be related. |
13 |
>>> |
14 |
>>>Yes and no. You're assuming that people don't use the layout on disk for digging |
15 |
>>>around without calling portage. Personally, I do. |
16 |
Not need to be related, but shouldn't be related. In essence this |
17 |
allows people to put the tree where-ever, as long as that storage |
18 |
mechanism supports the database operations required ( stuffing |
19 |
everything in a SQL db fex ). I don't know why someone would....but hey ;) |
20 |
>>> |
21 |
>>> |
22 |
>>>>I like the idea of using the first character of a package name as the |
23 |
>>>>sub-directory name. This can be extended more deeply as and when necessary to |
24 |
>>>>avoid over-large directories which cause problems on some filesystems. e.g. |
25 |
>>>>for sudo you get "s/sudo" and vim-sudo "v/vim-sudo". This is |
26 |
>>>>architecture-neutral, rsyncable, scalable, and not too difficult for users to |
27 |
>>>>parse manually (see later for searching through categories). If the algorithm |
28 |
>>>>portage would use to locate a package is such that it doesn't mandate the depth |
29 |
>>>>(i.e. tries "package", "p/package" if "p/" exists, "p/a/package" if "p/a/" |
30 |
>>>>exists) then overlays can have a different depth to the rsync tree; if you only |
31 |
>>>>have a few packages in overlay then they need not be in subdirectories at all. |
32 |
>>> |
33 |
>>>Re-asserting that the fs layout *does* matter, how is that more intuitive when trying |
34 |
>>>to track down the ebuild for dev-util/diffball ? |
35 |
>> |
36 |
>> |
37 |
>>The fact that the directory where diffball is is easily deducable by its |
38 |
>>name. As it is, I'd be a bit lost if I had to guess whether diffball is |
39 |
>>in app-arch or dev-util. Even if I remembered it was something |
40 |
>>dev-related I'd still be inclined to look in sys-devel. |
41 |
> |
42 |
> dev-util is accurate (it's a compressor, but a specialized variant, |
43 |
> same as patch is). From it's current fs location/layout, we get thus- |
44 |
> quick lookup on the atom, and inference of it's intentions. This is |
45 |
> why we have xml at the category level, for example. |
46 |
> |
47 |
> One thing that's being unstated also- it's implicitly stated that this |
48 |
> directory structure is somehow easier to look up a package. If you |
49 |
> know the _exact_ package name, maybe. Otherwise, you're falling back |
50 |
> to a search tool (which defeats to some degree the whole arguement for |
51 |
> flattened namespace). |
52 |
> Some quicky python, grouping by first char of the package name, and |
53 |
> you wind up with (top 8)- |
54 |
> 421, 521, 571, 582, 657, 663, 664, 746 |
55 |
Assuming the directories are ordered by letter, ( a,b,c,d ) and |
56 |
subdirectories if present as well, a bsearch wouldn't be bad. Both are |
57 |
ordered sets and you can quickly determine the location of a package in |
58 |
log(n) time. I don't see a big deal here. |
59 |
> Seperate directories within an individual directory. Say 'd' for |
60 |
> example, and we'll pretend 746 is the count of packages that start |
61 |
> with 'd'. That's a butload of directories to go digging in. |
62 |
> |
63 |
> The response would be, "well then extend it to the first two chars |
64 |
> after the first dir". You narrow it down, but add another layer of |
65 |
> dirs, again, for what gain? |
66 |
> |
67 |
> See, the thing I find odd about this thread/request is that |
68 |
> essentially breaking it down to first letter groupping, is being |
69 |
> argued as being _easier_ for people, while allowing multi cats, or |
70 |
> just flat out dropping the category aspect. The example above, imo, |
71 |
> proves otherwise. |
72 |
> |
73 |
> Keep in mind at this point, the discussion is whats easiest for |
74 |
> _humans_. What's easiest for code/comp is another matter, and (within |
75 |
> limits) can work with anything that's thrown at it. |
76 |
> |
77 |
> |
78 |
>>>How many directories deep would I have to go before I reached the |
79 |
>>>ebuild? |
80 |
>> |
81 |
>>Does it matter? You know the path exactly. It's p/portage. It's |
82 |
>>not ... "was it sys-apps/portage or app-portage/portage"? |
83 |
> |
84 |
> I know the path as sys-apps/portage already though. Doesn't that |
85 |
> count for something? :) |
86 |
> |
87 |
> Or, a bit more likely case, I know the type of the package, the |
88 |
> category, but don't recall it's exact name. What y'all are proposing |
89 |
> forces the user to use a tool, rather then just a quicky ls. |
90 |
|
91 |
*tongue in cheek* and what is ls but another tool for listing the |
92 |
contents of a directory :) |
93 |
|
94 |
>>>>Having said that, some things could be done now. If a flat package namespace |
95 |
>>>>is desirable, the existing package name clashes could be resolved by renaming |
96 |
>>>>the few packages that clash. |
97 |
>>> |
98 |
>>>74 packages, roughly, out of 9429 roughly. |
99 |
>> |
100 |
>>76/9295, which is not that bad, considering about half of them are |
101 |
>>emacs/xemacs related. |
102 |
> |
103 |
> 'cept either you, or someone else was proposing a totally flat |
104 |
> namespace, no cats in the atoms. That means the count of changes (the |
105 |
> 76 above is just # of conflicting packages) is around 19000, plus a |
106 |
> fairly large amount of portage modifications. |
107 |
> |
108 |
> |
109 |
>>>> Category could be added as a field in |
110 |
>>>>metadata.xml, so that a package could "belong" to multiple categories. |
111 |
>>>> The query/search tools could be enhanced to scan this metadata (perhaps including |
112 |
>>>>the current category directory as an implied entry in the metadata.xml). |
113 |
>>> |
114 |
>>>If that's the goal of the "belong to N categories" thread, strictly searching, |
115 |
>>>sure, although I don't like it. It can't become an atom for *DEPEND due to the cpv |
116 |
>>>nonconflicting bit. |
117 |
>> |
118 |
>>I personally want to see the category part *disappear* from the *DEPEND |
119 |
>>which is one of the reasons to advocate a flat tree. If the category (or |
120 |
>>part of it) goes in the package name, so be it, but at least there will |
121 |
>>be no package moves to break older ebuilds or outdated overlays. |
122 |
> |
123 |
> Frankly, you need to give a *really* damn good reason for why this is |
124 |
> better. I don't think it is, convince me otherwise. |
125 |
> |
126 |
> What do we gain from a flat namespace? |
127 |
> Right now, I can infer an atom out of a DEPEND string's purpose to |
128 |
> some degree, based upon it's category. To head off the "well you |
129 |
> don't need to know the category, you should know the packages |
130 |
> intentions if you're modifying the ebuild", that dodges the point; via |
131 |
> the category portion of an atom, I can infer at least -intention- of a |
132 |
> package. |
133 |
|
134 |
The CPV thing.....is a big fix :( |
135 |
|
136 |
> Ignoring changes required (have stated them already, no point in |
137 |
> sniping ya over it), what _exactly_ do we gain from the change? |
138 |
> ~brian |
139 |
-----BEGIN PGP SIGNATURE----- |
140 |
Version: GnuPG v1.4.1 (GNU/Linux) |
141 |
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org |
142 |
|
143 |
iQIVAwUBQoIghmzglR5RwbyYAQJa4w//WOTxQGm59JK96uX2MlLTlIG9kjFRhKTk |
144 |
AJjPybvOrJEngUuqhCogzxtsz0FXOX096bUyBO0CZb0mfN7hwW4jZIMDHycYD/kI |
145 |
AW22E/SrlH4iHi/UrQNzOm2kT6hgg1Vnnt/PqU/W1CqWF3xs8hFOYui61FW9U1WO |
146 |
Wq5vfxPZQd3cjRT1JQbIX3KJtmzYq8tnfWEaUo9kkSMlIWViFlvH0chEi7s61Na/ |
147 |
W/jfmscHBfx2y2pkITaRHO+JO3DgG412YKmfRe0JuOmcjGLwnrChQZqgSpTaE8e6 |
148 |
6d+ocqtTdAnJc52CbGCNN5RLnkmmYsOFGBtDEc4JKmYoRZZeWszI9QE6Dt+0i+mm |
149 |
rZAMtVvdRHE3A72cKF+4UiqvhIO2hAdzRE4i4m0h5WAsKrMDXIobeGunROHGCCyu |
150 |
ctsgH24OcTxX1D0syiQcvB+lvSyxDb2JBnd4gMSDpwEEQrZ9YxLkEVN830XZ6kaV |
151 |
FLxUj4zyl67iejabfNNBmTymV1i84z3BMeXKayrVp77NUF0swCOC6rlciCFfoSLQ |
152 |
N5vyFjwEcMsUWnSO2cq5laNDRqIjlw/YfO0Hiy55TCFi/vm5sH44rehntMyq1b3h |
153 |
xcLJhq7MIPmkfO2qZSZfD8ouB621bAlh4Vc+x+7kyLFaFRdAIQHYIY3rB3DFR5k9 |
154 |
ETcl3w/XVq8= |
155 |
=SN4n |
156 |
-----END PGP SIGNATURE----- |
157 |
-- |
158 |
gentoo-dev@g.o mailing list |