From: Alexis Ballier <aballier@gentoo.org>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2013-08-13
Date: Thu, 1 Aug 2013 17:40:12 -0400 [thread overview]
Message-ID: <20130801174012.5599eae9@gentoo.org> (raw)
In-Reply-To: <20130801210712.GA32416@linux1>
On Thu, 1 Aug 2013 16:07:12 -0500
William Hubbs <williamh@gentoo.org> wrote:
> 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.
Exactly :) so for the sake of consistency these should be in /usr and
not be lying to be some core enough program that doesn't need /usr.
[...]
> > 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 haven't tried but I seriously hope gettext can provide non localized
strings if it cannot access the localized ones. This is the very
least I would expect from a system without /usr.
> 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.
An announcement to the users and a council decision telling the
developer community to try to support separate usr or not are different
things. I'm all for the former, and it has already been done I think,
but your request sounded more like the latter.
> > 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 idea is to do things incrementally and opt-in. If all of a sudden
someone starts disabling gen_usr_ldscript and moving things to /usr,
I would bet there will be someone else yelling at him. If, on the other
hand, usr-moved systems have been in place for some time, are easy to
transition to, and nobody cares about maintaining a /usr barrier, I
would expect much less people to be against it being the default.
The variable also has the advantage that it makes it possible to
reverse course easily.
The end result will very likely be the same but one is perceived as
dictatorship and the other as democracy and freedom of choice :)
Alexis.
next prev parent reply other threads:[~2013-08-01 21:40 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-31 9:41 [gentoo-project] Call for agenda items - Council meeting 2013-08-13 Ulrich Mueller
2013-08-01 0:36 ` William Hubbs
2013-08-01 20:04 ` Alexis Ballier
2013-08-01 21:07 ` William Hubbs
2013-08-01 21:40 ` Alexis Ballier [this message]
2013-08-06 14:13 ` Build log locales (was: [gentoo-project] Call for agenda items - Council meeting 2013-08-13) Andreas K. Huettel
2013-08-06 15:39 ` [gentoo-project] Re: Build log locales Michael Weber
2013-08-06 15:52 ` Build log locales (was: [gentoo-project] Call for agenda items - Council meeting 2013-08-13) Michał Górny
2013-08-06 19:34 ` Alexis Ballier
2013-08-07 0:24 ` Mike Gilbert
2013-08-07 9:38 ` Andreas K. Huettel
2013-08-07 10:08 ` [gentoo-project] Re: Build log locales Ulrich Mueller
2013-08-07 10:14 ` Andreas K. Huettel
2013-08-06 16:07 ` Ulrich Mueller
2013-08-06 18:35 ` Mike Gilbert
2013-08-06 19:05 ` Rich Freeman
2013-08-06 19:26 ` Ulrich Mueller
2013-08-06 19:31 ` Michał Górny
2013-08-07 0:13 ` Mike Gilbert
2013-08-07 9:24 ` [gentoo-project] Council meeting: Tuesday 2013-08-13, 19:00 UTC Ulrich Mueller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130801174012.5599eae9@gentoo.org \
--to=aballier@gentoo.org \
--cc=gentoo-project@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox