1 |
On 25 June 2011 00:51, Nathan Phillip Brink <binki@g.o> wrote: |
2 |
> On Wed, Jun 22, 2011 at 11:20:40PM -0400, Wyatt Epp wrote: |
3 |
>> I bring this up because there are several packages with the same name |
4 |
>> and different qualification. Obviously, they'll have different tags |
5 |
>> because they're not the same thing, but neither should they share the |
6 |
>> same directory. So the simple solution is to just change the package |
7 |
>> names so we avoid collision and preserve our flat ontology (I've |
8 |
>> forgotten the objection to doing this; please forgive). |
9 |
> |
10 |
> I believe that the objection is that it is better to follow upstreams' |
11 |
> package names as directly as possible. This would look better and be |
12 |
> less confusing than having a package named git and git-core, like I've |
13 |
> seen elsewhere. Having categories would also prevent changing an |
14 |
> ebuild's name from upstream's name only for the sake of giving it a |
15 |
> unique name in Gentoo. |
16 |
|
17 |
You could possibly abuse the tag feature to solve this issue in |
18 |
interesting ways. |
19 |
|
20 |
Both could have: |
21 |
|
22 |
<tag class="common-name">git</tag> |
23 |
|
24 |
and thus people looking for 'git' would be more likely to find it. |
25 |
|
26 |
You could also perhaps extend this idea to other forms of metadata |
27 |
that users are likely to want to be able to search, perhaps: |
28 |
|
29 |
<tag class="provides-binary">git</tag> |
30 |
|
31 |
But that specific usage would probably be deemed slightly abusive. ( |
32 |
as for instance, you may wish to also list what the binary is usually |
33 |
called, and what gentoo ships it as to prevent collisions ) |
34 |
|
35 |
> |
36 |
> I think that in most cases, when package name collisions happen, the |
37 |
> colliding packages differ enough that they'd conceivably be in |
38 |
> different portage categories, letting them be uniquely identified in |
39 |
> Gentoo. If someone is planning on writing a new program, he likely |
40 |
> knows about already-existing alternatives to this package. The author |
41 |
> of a new sound editing suite would not name his suite `sox' because |
42 |
> the author cannot help but to know that media-sound/sox exists. But |
43 |
> someone writing some new sax thing might play off of `sax' and name it |
44 |
> `sox', though this is hypothetical ;-). |
45 |
|
46 |
|
47 |
But with this, you could store one as media-sound/sox-translator and |
48 |
the other as media-sound/sox-saxophone or something equally unique |
49 |
but arbitrary and tag them both with |
50 |
|
51 |
<tag class="common-name">sox</tag> |
52 |
|
53 |
Also, with this in mind, it may be better to have some types of tags |
54 |
that are only aggregated in an index of sorts, and others which are |
55 |
also perhaps made available as a tree of symlinks. |
56 |
|
57 |
> -- |
58 |
> binki |
59 |
> |
60 |
> Look out for missing or extraneous apostrophes! |
61 |
> |
62 |
|
63 |
|
64 |
|
65 |
-- |
66 |
Kent |
67 |
|
68 |
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, |
69 |
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" |
70 |
|
71 |
http://kent-fredric.fox.geek.nz |