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