| 1 |
Ulrich Mueller wrote: |
| 2 |
|
| 3 |
>>>>>> On Sun, 21 Sep 2008, Steve Long wrote: |
| 4 |
> |
| 5 |
>> That works for that specific case, yes, but it's still not a general |
| 6 |
>> solution, which is what BASH arrays were invented for. For instance, |
| 7 |
>> an ebuild author cannot specifically include a file with spaces, and |
| 8 |
>> ignore all the other files in the same directory. |
| 9 |
> |
| 10 |
> The better solution would be to rename a such strange files ... |
| 11 |
> How about an "edetox"? ;-) |
| 12 |
> |
| 13 |
Heh, I like the name (it brings lots of ideas to mind, none of them very |
| 14 |
achievable ;) but you get into the issue that you're changing the upstream |
| 15 |
naming, which goes against the principle of source transparency I |
| 16 |
personally love. It makes dealing with upstream projects much easier. |
| 17 |
|
| 18 |
> And I still don't see why we would need the most general solution for |
| 19 |
> a *default* function. There's always the possibility to write your own |
| 20 |
> src_install() for the few ebuilds that need it. |
| 21 |
> |
| 22 |
? Generality for lib functions seems like a desirable attribute to me. |
| 23 |
If we handle the general case with the defaults, it means less need for |
| 24 |
anyone to write more code, allowing them to focus on the interesting stuff |
| 25 |
and keeping the tree smaller. If we never have to worry about whether the |
| 26 |
base will cope with filenames, and only about quoting our own stuff, it |
| 27 |
makes development quicker. |
Archives