| 1 |
Ulrich Mueller wrote: |
| 2 |
|
| 3 |
>> As I said; generality in lib functions seems like a useful thing. |
| 4 |
> |
| 5 |
> Other ebuild variables are space separated lists, so why should DOCS |
| 6 |
> be an exception? |
| 7 |
> |
| 8 |
Because we're doing it right this time, while allowing existing usage. IOW |
| 9 |
you can quite happily continue to use your space-separated list and it |
| 10 |
won't matter. If you do ever need a bit more, it'll already be in place. If |
| 11 |
you never do, how will it hurt you? |
| 12 |
|
| 13 |
> So far nobody has shown a real-life example of an existing ebuild that |
| 14 |
> could profit from the array syntax. |
| 15 |
> |
| 16 |
I think Duncan answered the point quite while. In summary that's why for |
| 17 |
instance no filenames with spaces (leave alone all the other characters you |
| 18 |
can't deal with atm) can be safely handled by any of your ebuild structure, |
| 19 |
unless it comes from a glob, and is never manipulated or referenced in and |
| 20 |
of itself. (Unless you wish to go down the eval route, which believe me is |
| 21 |
not fun at all.) |
| 22 |
|
| 23 |
If you're saying "fine we don't need any more control in those packages" |
| 24 |
nothing I can say will be of any use. (NB: packages not programs.) Are you |
| 25 |
really arguing that reduced functionality is a good thing? |
| 26 |
|
| 27 |
>> There's a quote I read from what is imo a classic computing text[1] |
| 28 |
>> (from the 70s, never seen it referenced in any papers or anything): |
| 29 |
> |
| 30 |
>> "Why do we never have time to do it right, |
| 31 |
>> but always plenty of time to do it over." |
| 32 |
> |
| 33 |
> "Entia non sunt multiplicanda praeter necessitatem." |
| 34 |
> - Joh. Clauberg (1654) |
| 35 |
> |
| 36 |
"Let him who thinks it is not broken, not interrupt the person fixing it." |
| 37 |
Chinese proverb (wrongly attributed to some Ancient Roman.) |
Archives