| 1 |
On May 12, 2005, at 10:11 am, Patrick Lauer wrote: |
| 2 |
> On Wed, 2005-05-11 at 23:58 +0100, Stroller wrote: |
| 3 |
>> On May 11, 2005, at 8:10 pm, Ciaran McCreesh wrote: |
| 4 |
>>> |
| 5 |
>>> * Unique ID strings for packages, zynot style. Messy as hell though, |
| 6 |
>>> DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't |
| 7 |
>>> have |
| 8 |
>>> the same kind of ring to it... |
| 9 |
>> |
| 10 |
>> Maybe I'm just a messy person, but I really like this. |
| 11 |
> So does Microsoft. The registry has many entries where 128bit (?) |
| 12 |
> object-IDs are used. Very interesting to debug. |
| 13 |
|
| 14 |
I'm going to ignore that. This thread started because the current |
| 15 |
category/name naming convention causes interesting conditions. I |
| 16 |
appreciate that generally Microsoft Are Not Our Favourite Software |
| 17 |
Company, but giving them as an example doesn't inherently make unique |
| 18 |
IDs bad, and 128-bit ones are not necessary in this case. |
| 19 |
|
| 20 |
Also, before I start, I'd like to say that I know I'm not qualified to |
| 21 |
advocate this as a serious suggestion for adoption by Gentoo, so I'm |
| 22 |
just explaining _why I like it_. |
| 23 |
|
| 24 |
>> It prevents upstream naming collisions |
| 25 |
> But reduces readability for humans to zero. We don't want that. |
| 26 |
|
| 27 |
Humans are used to dealing with indexes - we remember phone numbers |
| 28 |
easily, and if we're looking up several things in a large volume, then |
| 29 |
we're used to using bookmarks or noting down page numbers. A six figure |
| 30 |
decimal packageID allows for a million packages in the Portage tree |
| 31 |
(and I'm assuming versions will be separate, anyway), a five figure hex |
| 32 |
ID would allow far more. |
| 33 |
|
| 34 |
Yes, arbitrary unique IDs would require an index tool to access ebuild |
| 35 |
name / category data, but surely there is little choice if |
| 36 |
naming-collisions are to be avoided and multiple categories are |
| 37 |
desired? Surely any human-focused naming convention will cause |
| 38 |
collisions and introduce potential for confusion? The current |
| 39 |
categories divide collisions into separate spaces, but they don't solve |
| 40 |
the problem of foo-player being eligible for both the media-CDplayers |
| 41 |
and audio-mp3rippers categories. |
| 42 |
|
| 43 |
> At least you haven't tried to optimize it all by using XML ... |
| 44 |
>> but the rest of us will use |
| 45 |
>> `esearch -o "%p\n" "" | grep -e category -e keyword`. |
| 46 |
> *head explodes* |
| 47 |
> No. |
| 48 |
|
| 49 |
That's the first time I used that command, but it only took me two |
| 50 |
minutes to look up & test. Since a dedicated index tool would clearly |
| 51 |
be required, I'm sure it would have better & more useful syntax. |
| 52 |
Currently I assume that Mr Harring searches for all the applications in |
| 53 |
a category by typing `ls -d /usr/portage/app-category/*` - wouldn't it |
| 54 |
be easier to use `esearch --category country`. Not only would it list |
| 55 |
them all, but multiple categories per package would also allow those to |
| 56 |
be shown that might debatably be categorised as "western". |
| 57 |
|
| 58 |
> ...It might make portage more resilient to one kind of problem, |
| 59 |
> but forget debugging then. |
| 60 |
|
| 61 |
Do we have 65000 unique packages in the tree? Would a four figure hex |
| 62 |
"part number" be that hard to remember when you're debugging package |
| 63 |
names? |
| 64 |
|
| 65 |
Again: I know I'm not qualified to advocate this as a serious |
| 66 |
suggestion for adoption by Gentoo, so I'm just explaining _why I like |
| 67 |
it_. |
| 68 |
|
| 69 |
Stroller. |
| 70 |
|
| 71 |
-- |
| 72 |
gentoo-dev@g.o mailing list |
Archives