Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[Alexis Ballier]

On Fri, 9 Nov 2012 09:32:47 -0600
William Hubbs <williamh@g.o> wrote:

> On Fri, Nov 09, 2012 at 08:33:55AM -0300, Alexis Ballier wrote:
> > On Thu, 8 Nov 2012 23:13:46 -0600
> > William Hubbs <williamh@g.o> wrote:
> >
> > > On Thu, Nov 08, 2012 at 08:46:29PM -0300, Alexis Ballier wrote:
> > > > On Thu, 8 Nov 2012 12:53:48 -0600
> > > > William Hubbs <williamh@g.o> wrote:
> > > >
> > > > > On Thu, Nov 08, 2012 at 07:15:57PM +0100, Fabian Groffen
> > > > > wrote:
> > > > > > On 08-11-2012 11:45:48 -0600, William Hubbs wrote:
> > > > > > > >    - approve/disapprove removal of gen_usr_ldscript
> > > > > > >
> > > > > > > A better way to put this is disabling gen_usr_ldscript on
> > > > > > > Linux. Some of the alternate platforms still use it, so I
> > > > > > > do not advocate killing the function.
> > > > > > > If we go forward with the plan, there is no reason the
> > > > > > > council should reject disabling gen_usr_ldscript on Linux
> > > > > > > that I am aware of.
> > > > > > >
> > > > > > > This also has to wait until the blockers are resolved on
> > > > > > > the tracker.
> > > > > >
> > > > > > Do you suggest to drop the point from the agenda?  I'd love
> > > > > > that.
> > > > >
> > > > > I believe we can drop the gen_usr_ldscript question, yes,
> > > > > because if everything else happens, we can just have the
> > > > > toolchain guys make it a noop on Linux.
> > > >
> > > > Something simpler and smoother imho is to just have a profile
> > > > variable that will make gen_usr_ldscript a noop, whatever CHOST
> > > > or the kernel is. New profiles are added with this variable
> > > > set, wide testing can be done without forcing anyone, and
> > > > voila. It is also simpler for maintaining the various OSes,
> > > > packages that used to install to / can just be changed to
> > > > install to /usr when this variable is set.
> > >
> > > I'm not trying to make packages install in /usr with this change.
> >
> > You are, since if a package in / needs a shared lib in /usr, there
> > is absolutely no point in installing the package in /.
> > nooping gen_usr_ldscript should come with a kind of plan for
> > the /usr move otherwise it is a bit ugly and somewhat loses its
> > point.
>
> No. All of this discussion about turning off gen_usr_ldscript on linux
> applies *after* separate /usr support (either by an initramfs or with
> the busybox[sep-usr] option) is implemented.

Which is the only viable solution, I agree.

> Once one of these options
> is implemented, /usr is always available when / is, so the "barrier"
> between / and /usr no longer exists. That just means you don't need
> to move shared libraries to / for binaries in / to link to them. It
> is the same as if you didn't put /usr on its own partition. To me,
> your argument here about disabling gen_usr_ldscript is like saying,
> if you put / and /usr on the same partition you should do a /usr move.

Then why would you put anything in /, besides static binaries, after all
this ? This is exactly what happened to udev & friends: after tons of
"""harmless""" additions that required /usr to be mounted, it has been
decided that separate /usr isn't going to work anymore. You're only
missing the last step: move it to /usr and at least have some benefits
instead of artificially maintaining a non-working /usr barrier for
historical reasons.

Again, what is the point of having a binary in /bin that links to a
library in /usr ?

> > > gen_usr_ldscript was introduced to force shaired libraries that
> > > upstream installs into /usr/lib to move to /lib and leave the
> > > static libraries in /usr/lib.
> >
> > It's rather the opposite actually: very few upstream specify their
> > install location, most default to /usr/local prefix because that's
> > autotools default. econf (ie us) sets the prefix to /usr.
> > gen_usr_ldscript is there because we don't need the static lib in /
> > (so that setting libdir to /lib is not an option) while the shared
> > lib is needed by binaries in /. We could just move the shared lib
> > to / but then the linker may link to the static lib if /usr/lib
> > comes before /lib in its search order, so we need a .so in the same
> > dir as the .a. For example FreeBSD solved that differently: they
> > symlink /lib/libfoo.so to /usr/lib/libfoo.so. Years ago we deemed
> > symlinks crossing the /usr barrier were bad, and here comes
> > gen_usr_ldscript. Note that I don't really see the difference
> > between a symlink crossing the /usr barrier and a ldscript
> > referencing a file outside of /usr but there must be some argument
> > behind.
>
> I spoke to flameeyes about symlinks crossing the /usr barrier, wrt
> another package, and he doesn't have a problem with this. I also have
> never seen any policy etc deaming them bad, but that's another
> discussion.

Well, last time I tried this, portage threw out big fat warnings for
such symlinks iirc. I'd call that policy :)

> All I'm saying is that implementing separate /usr support on linux
> eliminates the /->/usr barrier since / and /usr are always available
> at the same time, thus eliminating the need for gen_usr_ldscript.

Agreed, and also eliminating the need for separating /bin and /usr/bin

> > Let's move everything to /usr/local :) there is not really a 'where
> > upstream installs them' argument in this discussion, autotools is
> > specifically designed so that distributions can tweak the install
> > location. The fact that both the static and shared libs go to
> > libdir is only a shortcoming of autotools, some other build systems
> > make the distinction.
>
> I'm not familiar with many other build systems, so I can't really
> comment specifically to this. But, I wonder why you would need to
> separate where static and shared libs are installed.

Because sometimes you need to call gen_usr_ldscript :)

> > > Since we can tell we are on linux by looking at the chost/ctarget
> > > variables, and there is not an intention to change anything for
> > > *bsd or any other O/S, I am not sure I follow the need for a
> > > profile variable.
> >
> > Testing it. Testing the /usr move broadly.
> > You want gen_usr_ldscript on non-bootable systems (eg prefix,
> > mingw) to be (mostly) a noop too which you can't distinguish from
> > only CHOST.
>
> That has been done already by toolchain a while back. Take a look at
> the code in toolchain-funcs.eclass. There are very few platforms
> where this function does anything at all these days. It would just be
> a matter of removing linux from the platforms it supports.

Yeah, I remember that, and also when it completely broke freebsd-lib.
Maybe that's the reason why I'm reluctant to hardcoding this :)

[...]

> > > If they want to discuss the gen_usr_ldscript issue I'm not
> > > opposed to that, but that isn't really what I am asking for in
> > > this meeting.
> >
> > IMHO this needs a discussion on -dev before going through the
> > council.
>
>  I would send the patch to do this to -dev anyway, so at that time I
>  guess we could have folks apply it and rebuild their systems and see
>  what breaks.
>
>  Since applying the patch itself will not force any rebuilds, it
> should just end up being a natural migration; as things are rebuilt
> the libraries will move from /lib to /usr/lib with no harm being done.

If you stop there then all what you get is an artificial /usr and /
separation. According to Fedora, you gain much more with the /usr move
than the few bytes you save without ldscript. Please give me a reason
not to do an /usr move once you have covered all the needs to make it
possible.