Gentoo Archives: gentoo-dev

From: desultory <desultory@g.o>
To: gentoo-dev@l.g.o, Andrew Savchenko <bircoph@g.o>
Subject: Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
Date: Sat, 23 Feb 2019 20:39:26
Message-Id: d8bde60a-f496-2f51-e174-1af7c5907079@gentoo.org
In Reply to: Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files by Andrew Savchenko
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 >