1 |
On Thu, May 12, 2005 at 08:01:23PM +0100, Stroller wrote: |
2 |
> >>>* Unique ID strings for packages, zynot style. Messy as hell though, |
3 |
> >>>DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't |
4 |
> >>>have |
5 |
> >>>the same kind of ring to it... |
6 |
> >> |
7 |
> >>Maybe I'm just a messy person, but I really like this. |
8 |
> >So does Microsoft. The registry has many entries where 128bit (?) |
9 |
> >object-IDs are used. Very interesting to debug. |
10 |
> |
11 |
> I'm going to ignore that. This thread started because the current |
12 |
> category/name naming convention causes interesting conditions. I |
13 |
> appreciate that generally Microsoft Are Not Our Favourite Software |
14 |
> Company, but giving them as an example doesn't inherently make unique |
15 |
> IDs bad, and 128-bit ones are not necessary in this case. |
16 |
I suspect his point was that a 128-bit ID is holy hell on frail |
17 |
humans, versus a category/package string (which isn't). |
18 |
|
19 |
|
20 |
> >> It prevents upstream naming collisions |
21 |
> >But reduces readability for humans to zero. We don't want that. |
22 |
> |
23 |
> Humans are used to dealing with indexes - we remember phone numbers |
24 |
> easily |
25 |
Majority of the population don't have 1000+ phone numbers memorized |
26 |
though (which is roughly what we're talking about here for the package |
27 |
equiv). |
28 |
|
29 |
> and if we're looking up several things in a large volume, then |
30 |
> we're used to using bookmarks or noting down page numbers. A six figure |
31 |
> decimal packageID allows for a million packages in the Portage tree |
32 |
> (and I'm assuming versions will be separate, anyway), a five figure hex |
33 |
> ID would allow far more. |
34 |
Heh, counter example. Consider cell phones, people search for numbers |
35 |
based upon arbitrary names associated with the digits (one could view |
36 |
our category/package bit as the same). |
37 |
|
38 |
> Yes, arbitrary unique IDs would require an index tool to access ebuild |
39 |
> name / category data, but surely there is little choice if |
40 |
> naming-collisions are to be avoided and multiple categories are |
41 |
> desired? Surely any human-focused naming convention will cause |
42 |
> collisions and introduce potential for confusion? The current |
43 |
> categories divide collisions into separate spaces, but they don't solve |
44 |
> the problem of foo-player being eligible for both the media-CDplayers |
45 |
> and audio-mp3rippers categories. |
46 |
One problem, still need to resort to a human readable representation |
47 |
for specifying depends. Stating DEPEND="mpeg? ( \d{16} ) \d{16}" |
48 |
would be hell on devs. An automated approach could be leveled, but |
49 |
would need a *really* good reason to explain the loss of DEPEND |
50 |
readability via an editor. |
51 |
|
52 |
> >At least you haven't tried to optimize it all by using XML ... |
53 |
Antarus, was that you who tried the cache backend using xml? ;) |
54 |
|
55 |
> >>but the rest of us will use |
56 |
> >>`esearch -o "%p\n" "" | grep -e category -e keyword`. |
57 |
> >*head explodes* |
58 |
> >No. |
59 |
> That's the first time I used that command, but it only took me two |
60 |
> minutes to look up & test. Since a dedicated index tool would clearly |
61 |
> be required, I'm sure it would have better & more useful syntax. |
62 |
> Currently I assume that Mr Harring searches for all the applications in |
63 |
> a category by typing `ls -d /usr/portage/app-category/*` - wouldn't it |
64 |
> be easier to use `esearch --category country`. Not only would it list |
65 |
> them all, but multiple categories per package would also allow those to |
66 |
> be shown that might debatably be categorised as "western". |
67 |
actually... I use emerge -s @category |
68 |
emerge's speed is an issue granted, but not a reason to restructure |
69 |
(the speed issue isn't related to it, it's initialization overhead of |
70 |
import portage). |
71 |
|
72 |
> >...It might make portage more resilient to one kind of problem, |
73 |
> >but forget debugging then. |
74 |
> |
75 |
> Do we have 65000 unique packages in the tree? Would a four figure hex |
76 |
> "part number" be that hard to remember when you're debugging package |
77 |
> names? |
78 |
Yeah, imo. What gain is there in having to memorize 1623 is openssh, |
79 |
just so I can comprehend the DEPEND string when glancing over an |
80 |
ebuild? |
81 |
|
82 |
> Again: I know I'm not qualified to advocate this as a serious |
83 |
> suggestion for adoption by Gentoo, so I'm just explaining _why I like |
84 |
> it_. |
85 |
content is what matters, not the speaker or his/her qualifications :) |
86 |
~brian |
87 |
-- |
88 |
gentoo-dev@g.o mailing list |