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

[Alexis Ballier]

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.

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

> So, gentoo linux is diverging from upstream's install locations by
> splitting up where we install libraries. All I'm proposing is that on
> linux we should remove that divergance and put libraries where
> upstream installs them.

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.

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

> Again, I'm not asking that the council vote on this at this vote, I am
> just asking that they approve the two methods of supporting separate
> /usr on linux and approve the action plan of putting out a newsitem
> and giving a time window for everyone to migrate to either initramfs
> or busybox[sep-usr].

Fair enough :)

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