1 |
On 02/23/19 03:42, Andrew Savchenko wrote: |
2 |
> On Fri, 22 Feb 2019 23:30:15 -0500 desultory wrote: |
3 |
>> On 02/20/19 02:36, Michał Górny wrote: |
4 |
>>> On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote: |
5 |
>>>>>>>>> On Wed, 20 Feb 2019, Matt Turner wrote: |
6 |
>>>> |
7 |
>>>> |
8 |
>>>>> # Don't install libtool archives (even for modules) |
9 |
>>>>> - prune_libtool_files --all |
10 |
>>>>> + find "${D}" -name '*.la' -delete || die |
11 |
>>>> |
12 |
>>>> Maybe restrict removal to regular files, i.e. add "-type f"? |
13 |
>>> |
14 |
>>> I suppose you should have spoken up when people started adopting that |
15 |
>>> 'find' line all over the place. Though I honestly doubt we're going to |
16 |
>>> see many packages installing '*.la' non-files. |
17 |
>>> |
18 |
>> Just so we are all clear here: your argument is that more fully correct |
19 |
>> approaches should not be considered in the present and future because |
20 |
>> less fully correct approaches were implemented in the past? And, |
21 |
>> further, that since nothing matching a specific pattern happens to come |
22 |
>> to your mind at he moment, such things do not exist? Perhaps dialing |
23 |
>> back the rhetoric from 11 and considering feedback as an opportunity to |
24 |
>> improve existing code is called for in this case, among others. |
25 |
> |
26 |
> If we are going to improve code, we should also use find -O3. |
27 |
> |
28 |
Please forgive my presumption, but I am going to infer that your comment |
29 |
was neither meant to display gross ignorance of find (1) nor as a |
30 |
strawman, but was instead merely a joke; and on that basis ask you a |
31 |
question. |
32 |
|
33 |
Why, in your opinion, should it be acceptable for a member of QA to |
34 |
dismiss commentary on a piece of code on grounds that he knows to be |
35 |
spurious? Especially code that has been noted, in this very thread, to |
36 |
encounter cases where it does the wrong thing. Especially when the |
37 |
proposed change actually removes a class of potential misbehavior of the |
38 |
code in question. |
39 |
|
40 |
The proposed change hardly appears to be difficult to implement, |
41 |
difficult to maintain, expansive in scale, or obscure in nature; so none |
42 |
of those concerns would appear to apply. Though it does miss at least |
43 |
one obvious class of potential misbehavior, but that was not the basis |
44 |
on which it was dismissed. |
45 |
|
46 |
I eagerly await your insight. |
47 |
|
48 |
> |
49 |
> Best regards, |
50 |
> Andrew Savchenko |
51 |
> |