1 |
El dom, 31-10-2010 a las 14:56 +0100, Diego Elio Pettenò escribió: |
2 |
> Il giorno dom, 31/10/2010 alle 03.30 -0100, Jorge Manuel B. S. Vicetto |
3 |
> ha scritto: |
4 |
> > As agreed in the meeting, as a first draft, we have that "the motion |
5 |
> > is |
6 |
> > to drop la files, when appropriate, through the use of a function in |
7 |
> > eutils that will only be called if the static-libs use flag is not set |
8 |
> > or unless the package relies on pkg-config". |
9 |
> |
10 |
> Let's differentiate already: |
11 |
> |
12 |
> For *plugin* .la files, they should removed if the software is not |
13 |
> relying on them to load its plugins, see [1]. This is the case for PAM, |
14 |
> Python, Ruby and I guess Perl, which commonly receive stupid .la files |
15 |
> in their paths. Repeat after me: they should just all be deleted _right |
16 |
> now_ since they are not going to be linked by anyone else and thus |
17 |
> Portage 2.1.9 is not making any difference. |
18 |
> |
19 |
|
20 |
In that case, I think the work on these cases should start as soon as |
21 |
possible, but I think that getting bugs reported (probably from your |
22 |
next tinderbox run if possible) would help. For example, I have just |
23 |
seen in my system that packages like dev-python/pyorbit and |
24 |
dev-libs/libgamin are installing these .la files that should not be |
25 |
needed, but I am sure lots of other python packages are also |
26 |
affected :-/. |
27 |
|
28 |
But I would also like to know what would be the best way to drop them in |
29 |
these cases: |
30 |
- For python, looks like calling python_clean_installation_image from |
31 |
python.eclass at src_install phase is the proper way. |
32 |
- For pam, ruby or perl I have no idea :-( |
33 |
|
34 |
Thanks |