1 |
On 03-10-2010 12:53, David Leverton wrote: |
2 |
> On 2 October 2010 20:54, Jorge Manuel B. S. Vicetto |
3 |
> <jmbsvicetto@g.o> wrote: |
4 |
>> Given the recent activity around .la files and conflict about how to |
5 |
>> deal with them, I propose we discuss this issue in this mailing list, |
6 |
>> and take this issue to the council. |
7 |
>> That way, we can make a global decision, taking into account all the |
8 |
>> arguments for and against, find a balance, opt for a policy, inform |
9 |
>> users and developers about it and move on. |
10 |
> |
11 |
> While I do agree that the underlying problem we're trying to solve is |
12 |
> worth solving, I do have a couple of small concerns about how it's |
13 |
> being done. The first is that it seems people are judging whether a |
14 |
> particular .la file is "needed" by checking whether anything currently |
15 |
> in the tree needs it, but this doesn't take into account anything that |
16 |
> /isn't/ in the tree yet. |
17 |
|
18 |
This is a very good point. However, in the case of out-of-tree packages, |
19 |
I think most "regular" users just use ebuilds from bugzilla (and third |
20 |
party places like forums etc). Users that contribute their cooked |
21 |
ebuilds should know more or less what are doing, so I guess they will |
22 |
have the corresponding packages patched in one way or another, if they |
23 |
require a certain .la file. |
24 |
|
25 |
> The second is that removing .la files |
26 |
> everywhere makes it hard for people to experiment with alternative |
27 |
> solutions, as testing an alternative would require modifying all the |
28 |
> affected ebuilds to stop removing them. (And yes, I am interested in |
29 |
> doing so myself, although time constraints mean it might not |
30 |
> happening.) |
31 |
> |
32 |
> Would it be too much trouble to have a standardised variable that |
33 |
> means .la files should be kept? It maybe /shouldn't/ be exposed as a |
34 |
> USE flag because very few people will need it, but if it's easy to |
35 |
> implement (maybe by having an eutils function to do the removal, |
36 |
> checking the variable first) it would remove any objections I could |
37 |
> imagine. |
38 |
|
39 |
This seems like a very good solution. For example - usually, people |
40 |
building packages manually just want the build process to work. They |
41 |
don't want to spend time making an ebuild or digging around. One being |
42 |
able to simply |
43 |
USE="libtool" emerge foo |
44 |
to restore the foo's .la files would be great. |
45 |
|
46 |
A gentoo page properly indexed in Google and explaining what to do when |
47 |
a libtool library is not found, should take care of most. |
48 |
|
49 |
Another positive point about an .la USE flag is that users are already |
50 |
used to put their USE flags on bugzilla, which should help package |
51 |
maintainers to acknowledge .la related problems. |
52 |
> |
53 |
> As I said, these are minor points, and I wouldn't expect people to go |
54 |
> to great effort to satisfy them. Just something to consider. |
55 |
> |
56 |
|
57 |
Me being one of the persons that initially contributed code to allow |
58 |
portage to fix .la files, I'm indeed happy to see the direction Gentoo |
59 |
is heading. Libtool archives were (and still are for those not using |
60 |
portage) a pain in the ass for cross-compilation. |
61 |
|
62 |
Regards, |
63 |
- Angelo |