Re: [gentoo-project] Call for agenda items - Council meeting 2013-08-13

[William Hubbs <williamh@gentoo.org>]

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

On Thu, Aug 01, 2013 at 04:04:34PM -0400, Alexis Ballier wrote:
> On Wed, 31 Jul 2013 19:36:14 -0500
> William Hubbs <williamh@gentoo.org> wrote:
> [...]
> > First, we will not have to worry any more about making sure all of the
> > libraries needed by binaries in /{bin,sbin} are in /lib*. Also, we
> > will not have to be concerned about programs on / trying to read data
> > from /usr/share in early boot.
 
 First off, this is all related to Linux only, so keep that in mind when
 I answer below.

> Why are those programs in / in the first place ? If they can't work
> without /usr they are sort of useless in /.

Not really. if you use an initramfs or some early boot mechanism like
that to make sure / and /usr are mounted at the same time, that
separation is irrelivant.

> > Because of this information, I propose that we vote not to
> > require maintainers to support separate /usr configurations without an
> > initramfs or some other early boot mechanism.
> 
> 'not to require' leaves it up to the maintainers e.g. if they want to
> call gen_usr_ldscript or install into /, right ? Or does that imply they
> should not do it ?
 
 I'll talk about gen_usr_ldscript below.

> The current requirement imposes some consistency, and lifting it would
> leave us with some bastardized system where some random files are in /
> and others in /usr.
 
As I said in my original proposal, there is or is not a
 requirement depending on who you talk to and where you read. The
 summary of the meeting doesn't say anything about such a requirement,
 even though the log does, so it is not a clear situation right now.

> I have no opinion whether separate usr should be supported or not: I
> have not been using this layout since years. However, I strongly prefer
> some kind of consistency: The traditional layout with a minimal / to
> boot or the usr move both have their advantages; if we go for something
> in between we get none of them.

What we currently have is in between. To really make separate /usr work
would require a /share top level directory, patching gettext at least to
look in both /usr/share/locale and /share/locale, and who knows what else.

I'm not advocating the /usr merge at this time, maybe later, but right
now I just want to make it official that we do not support separate /usr
without an early boot mechanism like an initramfs or the sep-usr flag on
busybox under Linux.

> 
> I think most of what is in / currently is maintained by base-system@.
> base-system@, or the council, could decide to provide a way to drop the
> self-contained / properly. Say, you have to define a variable in
> make.conf, let's call it GENTOO_USR_MOVE, and this variable would no-op
> gen_usr_ldscript (they waste space if /usr is required anyway) and then
> some packages could decide to install to /usr instead of / if this
> variable is set, etc. Once this is ready, you can define this variable
> in the profiles and get all the profit advertised by Fedora usr move.

(putting my base-system hat on)

I'm not sure why we would need a profile variable like you are
suggesting.

The reason gen_usr_ldscript came into being is that we were already
moving shared libraries from /usr/lib* to /lib* and we hit bug 4411, where the
linker was choosing a static library in /usr/lib over a dynamic library
in /lib. Besides moving the shared library from /usr/lib* to /lib*, it
writes a linker script in /usr/lib* to redirect the linker to look for
the shared library in /lib*. So, I think it has to be disabled
completely on Linux before the /usr move can be considered. It is smart
enough to be able to tell when it is on linux (by checking the CHOST
value like it already does for some things), so at some point I want to
talk to the rest of base-system and toolchain to figure out a sane
procedure for turning it off on linux. Again that has to be done after
this vote.

William


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