1 |
On 11/13/2014 02:29 AM, Alexander Berntsen wrote: |
2 |
> On 13/11/14 02:22, Zac Medico wrote: |
3 |
>> +if "case-insensitive-fs" in portage.settings.features: |
4 |
>> + FIND_EXTANT_CONFIGS = \ |
5 |
>> + FIND_EXTANT_CONFIGS.replace("-name '._cfg", "-iname '._cfg") |
6 |
>> + |
7 |
> Splitting inside the replace will look nicer following PEP indentation |
8 |
> (as you won't need the '\'). |
9 |
|
10 |
Okay, I'll re-format it as you've suggested. |
11 |
|
12 |
>> +Use case\-insensitive file name comparisions when merging and unmerging |
13 |
>> +files. |
14 |
>> +.TP |
15 |
> Maybe mention a) that most people can ignore this option, and b) who |
16 |
> it's actually for. Kind of in the kernel option help style. |
17 |
|
18 |
Okay, I'll add something about it only being needed for case-insensitive |
19 |
file systems, which are usually not used. |
20 |
|
21 |
> |
22 |
> In general I don't like this patch. It handles a bunch of cases separately |
23 |
> by doing lower(), when I think instead it should be handled implicitly. |
24 |
> The data should be in a structure such that it knows whether it is supposed |
25 |
> to be upper or lowercase, and whatever's dealing with it should deal with |
26 |
> it accordingly, rather than checking "is this case insensitive? OK |
27 |
> lowercase it before sending it wherever". |
28 |
|
29 |
Aside from the ConfigProtect constructor, which has a new |
30 |
case_insensitive keyword parameter, all affected methods handle case |
31 |
transformations "implicitly", as far as API consumers are concerned. |
32 |
|
33 |
However, we could improve efficiency for some usage patterns by |
34 |
providing an alternative to dblink.getcontents that is oriented toward |
35 |
case-insensitive handling. For example, every single |
36 |
dblink._match_contents call currently has to transform all names to |
37 |
lowercase, and generate a reverse mapping from lowercase back to |
38 |
preserved case. The dblink._match_contents method would be more |
39 |
efficient if we created an alternative to dblink.getcontents that |
40 |
handled the transformations and cached the results. I intentionally did |
41 |
not implement this optimization yet, since it's probably better to do it |
42 |
in a separate patch, rather than complicate the current patch. |
43 |
|
44 |
> But if you think this is the best way, I'm not going to stand in the way of this patch. |
45 |
|
46 |
As discussed above, think the current approach is pretty reasonable, |
47 |
though I would like to optimize it with a separate patch. |
48 |
-- |
49 |
Thanks, |
50 |
Zac |