| 1 |
lxnay@××××××××××××.org wrote: |
| 2 |
> |
| 3 |
> |
| 4 |
> On Mon, May 25, 2009 at 3:43 PM, Alex Legler <a3li@g.o> wrote: |
| 5 |
>> On So, 2009-05-24 at 20:04 +0200, lxnay@××××××××××××.org wrote: |
| 6 |
>>> [...] |
| 7 |
>>> >> app-admin/equo (sabayon overlay -- Entropy Framework client) supports |
| 8 |
>>> >> the postfix "@repository" to let users force the installation of a |
| 9 |
>>> >> package from a specific repository. |
| 10 |
>>> > |
| 11 |
>>> > @ is used by Portage for sets. Paludis has been using ::repo for repo |
| 12 |
>>> > dependencies for years. Why not go with the established syntax? |
| 13 |
>>> |
| 14 |
>>> I wrote "postfix" not "prefix". Sets use "@" prefix. |
| 15 |
>> |
| 16 |
>> Your @ is still a prefix for the repository name. |
| 17 |
> |
| 18 |
> Yeah but "emerge @overlay" would be obviously illegal. So your argument |
| 19 |
> is a bit pointless ;) |
| 20 |
> |
| 21 |
>> |
| 22 |
>> For usability's sake, please don't do this. I can imagine users getting |
| 23 |
>> confused over the different meanings of the @ sign. |
| 24 |
>> |
| 25 |
>> I do not want to trigger a discussion like the one PHP had when choosing |
| 26 |
>> namespace separators, but we got the "::" established in Paludis and |
| 27 |
>> Paludis is used by way more Gentoo people than equo. |
| 28 |
> |
| 29 |
> "::" C++/PHP/whatever separator has nothing to do with the purpose of |
| 30 |
> "@overlay". |
| 31 |
Personally I think the PHP namespace syntax issue is a very good |
| 32 |
analogy. There's an established syntax, even if it's not a written |
| 33 |
standard, already used in a very similar situation, and that should be |
| 34 |
taken into account. |
| 35 |
|
| 36 |
> Paludis is not a Gentoo project and doesn't follow Gentoo features |
| 37 |
> validation rules. |
| 38 |
> So is Entropy. If Paludis has its own syntax it doesn't automatically |
| 39 |
> mean that Gentoo Portage *has to* follow it. |
| 40 |
> I prefer a more democratic way => discussing here. |
| 41 |
|
| 42 |
As far as I can see, a discussion is happening. You started a discussion |
| 43 |
here and others mentioned that there is a specific syntax already used |
| 44 |
for this by a very similar application. |
| 45 |
|
| 46 |
You appear to be the only one who's arguing against that syntax. As a |
| 47 |
user, I have to agree that using @ for multiple purposes, even if it |
| 48 |
can't be applied to the same purposes in different locations, is |
| 49 |
potentially confusing, even if not just plain silly. |
| 50 |
|
| 51 |
As a side note, I think I've read somewhere that it may in the future be |
| 52 |
possible to specify sets in package.* (which I assume would be done |
| 53 |
using the @set-name syntax), but can't remember where off-hand. This may |
| 54 |
have just been a suggestion, but if it ever is implemented, it would |
| 55 |
surely add to the confusion. |
| 56 |
|
| 57 |
AllenJB |
| 58 |
|
| 59 |
> |
| 60 |
>> |
| 61 |
>> So it only seems logical to me to use the wider-known and at the same |
| 62 |
>> time ambiguity-free "operator". |
| 63 |
>> |
| 64 |
>> Alex |
Archives