1 |
On Thu, Nov 08, 2012 at 02:07:23PM -0300, Alexis Ballier wrote: |
2 |
> On Tue, 30 Oct 2012 11:38:20 -0500 |
3 |
> William Hubbs <williamh@g.o> wrote: |
4 |
> |
5 |
> [...] |
6 |
> > > The end result of this assumption is that the use of |
7 |
> > > gen_usr_ldscript() and the move of libs from /usr/lib to /lib will |
8 |
> > > become deprecated, correct? I think it's pertinent to note this (or |
9 |
> > > whatever other changes will then be requested/required for Council |
10 |
> > > to decide on) within this discussion, if not also within the |
11 |
> > > "plan".. |
12 |
> > |
13 |
> > On Linux, yes, you are correct. I wouldn't propose touching it for the |
14 |
> > *bsd platforms. |
15 |
> > |
16 |
> > Also, once everyone switches over, this deprecation would be |
17 |
> > transparent. The calls to gen_usr_ldscript would be removed from |
18 |
> > ebuilds where possible, and the function itself could be disabled on |
19 |
> > linux. Once this is done, when packages are rebuilt, the libraries |
20 |
> > would migrate back to /usr/lib. |
21 |
> |
22 |
> |
23 |
> (I hadn't seen that thread.) |
24 |
> |
25 |
> Removing it from ebuilds implies touching it for *bsd platforms. A lot |
26 |
> of ebuilds are shared between the g/*bsd and g/linux port, that's |
27 |
> somewhat the point of the whole thing. Of course, there may be |
28 |
> linux-only packages where the calls to gen_usr_ldscript will become |
29 |
> useless, but in general these calls should remain and the function |
30 |
> shall be a no-op on platforms where this is desired. |
31 |
|
32 |
That's what I said. The calls could be removed "where possible", |
33 |
meaning linux-only ebuilds. You can tell from the KEYWORDS which |
34 |
ebuilds this would apply to. :-) |
35 |
|
36 |
William |