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

[William Hubbs <williamh@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 6269 bytes --]

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@gentoo.org> 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@gentoo.org> 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. 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.

> > 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.

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.

> 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.

> > 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.

Once again, this has nothing to do with the /usr move, just eliminating
the /->/usr barrier.

> > 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.

 William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]