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