1 |
On Fri, Nov 09, 2012 at 08:33:55AM -0300, Alexis Ballier wrote: |
2 |
> On Thu, 8 Nov 2012 23:13:46 -0600 |
3 |
> William Hubbs <williamh@g.o> wrote: |
4 |
> |
5 |
> > On Thu, Nov 08, 2012 at 08:46:29PM -0300, Alexis Ballier wrote: |
6 |
> > > On Thu, 8 Nov 2012 12:53:48 -0600 |
7 |
> > > William Hubbs <williamh@g.o> wrote: |
8 |
> > > |
9 |
> > > > On Thu, Nov 08, 2012 at 07:15:57PM +0100, Fabian Groffen wrote: |
10 |
> > > > > On 08-11-2012 11:45:48 -0600, William Hubbs wrote: |
11 |
> > > > > > > - approve/disapprove removal of gen_usr_ldscript |
12 |
> > > > > > |
13 |
> > > > > > A better way to put this is disabling gen_usr_ldscript on |
14 |
> > > > > > Linux. Some of the alternate platforms still use it, so I do |
15 |
> > > > > > not advocate killing the function. |
16 |
> > > > > > If we go forward with the plan, there is no reason the council |
17 |
> > > > > > should reject disabling gen_usr_ldscript on Linux that I am |
18 |
> > > > > > aware of. |
19 |
> > > > > > |
20 |
> > > > > > This also has to wait until the blockers are resolved on the |
21 |
> > > > > > tracker. |
22 |
> > > > > |
23 |
> > > > > Do you suggest to drop the point from the agenda? I'd love |
24 |
> > > > > that. |
25 |
> > > > |
26 |
> > > > I believe we can drop the gen_usr_ldscript question, yes, because |
27 |
> > > > if everything else happens, we can just have the toolchain guys |
28 |
> > > > make it a noop on Linux. |
29 |
> > > |
30 |
> > > Something simpler and smoother imho is to just have a profile |
31 |
> > > variable that will make gen_usr_ldscript a noop, whatever CHOST or |
32 |
> > > the kernel is. New profiles are added with this variable set, wide |
33 |
> > > testing can be done without forcing anyone, and voila. It is also |
34 |
> > > simpler for maintaining the various OSes, packages that used to |
35 |
> > > install to / can just be changed to install to /usr when this |
36 |
> > > variable is set. |
37 |
> > |
38 |
> > I'm not trying to make packages install in /usr with this change. |
39 |
> |
40 |
> You are, since if a package in / needs a shared lib in /usr, there is |
41 |
> absolutely no point in installing the package in /. |
42 |
> nooping gen_usr_ldscript should come with a kind of plan for the /usr |
43 |
> move otherwise it is a bit ugly and somewhat loses its point. |
44 |
|
45 |
No. All of this discussion about turning off gen_usr_ldscript on linux |
46 |
applies *after* separate /usr support (either by an initramfs or with |
47 |
the busybox[sep-usr] option) is implemented. Once one of these options |
48 |
is implemented, /usr is always available when / is, so the "barrier" between |
49 |
/ and /usr no longer exists. That just means you don't need to move |
50 |
shared libraries to / for binaries in / to link to them. It is the same |
51 |
as if you didn't put /usr on its own partition. To me, your argument |
52 |
here about disabling gen_usr_ldscript is like saying, if you put / and |
53 |
/usr on the same partition you should do a /usr move. |
54 |
|
55 |
> > gen_usr_ldscript was introduced to force shaired libraries that |
56 |
> > upstream installs into /usr/lib to move to /lib and leave the static |
57 |
> > libraries in /usr/lib. |
58 |
> |
59 |
> It's rather the opposite actually: very few upstream specify their |
60 |
> install location, most default to /usr/local prefix because that's |
61 |
> autotools default. econf (ie us) sets the prefix to /usr. |
62 |
> gen_usr_ldscript is there because we don't need the static lib in / (so |
63 |
> that setting libdir to /lib is not an option) while the shared lib is |
64 |
> needed by binaries in /. We could just move the shared lib to / but |
65 |
> then the linker may link to the static lib if /usr/lib comes |
66 |
> before /lib in its search order, so we need a .so in the same dir as |
67 |
> the .a. For example FreeBSD solved that differently: they |
68 |
> symlink /lib/libfoo.so to /usr/lib/libfoo.so. Years ago we deemed |
69 |
> symlinks crossing the /usr barrier were bad, and here comes |
70 |
> gen_usr_ldscript. Note that I don't really see the difference between a |
71 |
> symlink crossing the /usr barrier and a ldscript referencing a file |
72 |
> outside of /usr but there must be some argument behind. |
73 |
|
74 |
I spoke to flameeyes about symlinks crossing the /usr barrier, wrt |
75 |
another package, and he doesn't have a problem with this. I also have never |
76 |
seen any policy etc deaming them bad, but that's another discussion. |
77 |
|
78 |
All I'm saying is that implementing separate /usr support on linux |
79 |
eliminates the /->/usr barrier since / and /usr are always available at |
80 |
the same time, thus eliminating the need for gen_usr_ldscript. |
81 |
|
82 |
> Let's move everything to /usr/local :) there is not really a 'where |
83 |
> upstream installs them' argument in this discussion, autotools is |
84 |
> specifically designed so that distributions can tweak the install |
85 |
> location. The fact that both the static and shared libs go to libdir is |
86 |
> only a shortcoming of autotools, some other build systems make the |
87 |
> distinction. |
88 |
|
89 |
I'm not familiar with many other build systems, so I can't really |
90 |
comment specifically to this. But, I wonder why you would need to |
91 |
separate where static and shared libs are installed. |
92 |
|
93 |
> > Since we can tell we are on linux by looking at the chost/ctarget |
94 |
> > variables, and there is not an intention to change anything for *bsd |
95 |
> > or any other O/S, I am not sure I follow the need for a profile |
96 |
> > variable. |
97 |
> |
98 |
> Testing it. Testing the /usr move broadly. |
99 |
> You want gen_usr_ldscript on non-bootable systems (eg prefix, mingw) to |
100 |
> be (mostly) a noop too which you can't distinguish from only CHOST. |
101 |
|
102 |
That has been done already by toolchain a while back. Take a look at the |
103 |
code in toolchain-funcs.eclass. There are very few platforms where this |
104 |
function does anything at all these days. It would just be a matter of |
105 |
removing linux from the platforms it supports. |
106 |
|
107 |
Once again, this has nothing to do with the /usr move, just eliminating |
108 |
the /->/usr barrier. |
109 |
|
110 |
> > If they want to discuss the gen_usr_ldscript issue I'm not opposed to |
111 |
> > that, but that isn't really what I am asking for in this meeting. |
112 |
> |
113 |
> IMHO this needs a discussion on -dev before going through the council. |
114 |
|
115 |
I would send the patch to do this to -dev anyway, so at that time I |
116 |
guess we could have folks apply it and rebuild their systems and see |
117 |
what breaks. |
118 |
|
119 |
Since applying the patch itself will not force any rebuilds, it should |
120 |
just end up being a natural migration; as things are rebuilt the |
121 |
libraries will move from /lib to /usr/lib with no harm being done. |
122 |
|
123 |
William |