From: Ulrich Mueller <ulm@gentoo.org>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] Support for separate /usr
Date: Sun, 11 Aug 2013 16:59:36 +0200 [thread overview]
Message-ID: <20999.42712.964581.102162@a1i15.kph.uni-mainz.de> (raw)
In-Reply-To: <CAGfcS_keiWtGjJ04yhkrSS2J682BYQBch9s1C74x9eHtB35gdQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4199 bytes --]
>>>>> On Thu, 1 Aug 2013, Rich Freeman wrote:
> On Thu, Aug 1, 2013 at 4:04 PM, Alexis Ballier <aballier@gentoo.org>
> wrote:
>> 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.
> I tend to loosely agree here.
> My inclination right now is to support this proposal if either of
> the following is true:
> 1. Somebody explains that right now the absence of a decision is
> causing them actual problems (extra work, limitations, whatever).
> 2. This becomes necessary to enable some larger long-term goal,
> which has received council approval.
> #2 was basically covered by Alexis already.
> Regarding #1, I informally emailed the base-system maintainers a
> week ago about whether there was any need to revisit last year's
> decision. I didn't really get a sense that anybody really needed the
> council to step in now. I recognize that William is also a
> base-system maintainer so if he wants to state that he is subject to
> some kind of extra work or such supporting separate /usr without an
> early boot workaround I'll certainly be sympathetic.
> I do favor the dropping of support for separate /usr without an
> early boot workaround. I just don't think the council should
> actually step in until somebody needs us to, or as part of some
> larger plan. If the base-system maintainers have things under
> control, better to let them handle it.
I mostly agree with aballier and rich0.
It so happened that I had chaired the 2012-04 council meeting and it
seems that I failed to make sure that the vote was on a well-defined
question.
Trying to interpret or clarify that 2012-04 vote won't help much:
That a separate /usr _with_ an initramfs is supported is self-evident,
so it would have been moot to vote on this. OTOH, a separate /usr
being supported _without_ an initramfs raises the question what
"supported" means. Obviously there are situations where such a
configuration doesn't currently work, and it is not even clear if
making it work would be feasible. For example, if a user chooses to
emerge sys-apps/shadow with cracklib and pam USE flags enabled, then
he cannot expect it to be fully functional without /usr being mounted.
So there _is_ some amount of inconsistency already, and maybe it's not
even fixable, given the many possible configurations with different
USE flags. (For a binary distro, it may be easier.) However, for basic
configurations, like the one used for stage3, the root file system
still seems to be self-supporting.
I think one thing to consider is where we want to go in the long term.
The FHS [1] specifies binaries that must be in /bin and /sbin, mainly
sys-apps/coreutils, sys-apps/util-linux, sys-apps/shadow, and a
handful of others (that are related to networking, archiving, system
boot and shutdown). Shared libraries needed by these binaries must be
in /lib*.
Shall we stick to this FHS requirement, as far as it is technically
feasible, or shall we do the /usr merge which also has benefits? Or
some middle ground between these two solutions? (But I'm with aballier
here, that would lead to further inconsistencies and we won't get the
advantages of either solution.) Are we even ready to decide on this
question yet?
What shall we do in the short term? For the upcoming council meeting,
the following questions come to mind:
- Do we need any new decisions at all? Or are we confident that
maintainers (mainly base-system) will do the right thing?
- Should binaries stay in /bin or /sbin if the FHS says so, or if
they're otherwise needed for booting? (For the time being, until we
make up our mind about the /usr merge?)
- Are shared libraries needed by binaries in /bin or /sbin to be
installed in /lib*?
- Do we discourage moving further programs from /usr to /, in order
to keep the root filesystem at a small size? Even if this causes
inconsistencies in some configurations?
Ulrich
[1] http://www.linuxbase.org/betaspecs/fhs/fhs/ch03.html
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
prev parent reply other threads:[~2013-08-11 14:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-01 21:16 [gentoo-project] Support for Seperate /usr Rich Freeman
2013-08-01 21:42 ` Andreas K. Huettel
2013-08-01 23:26 ` Rich Freeman
2013-08-01 22:49 ` William Hubbs
2013-08-01 22:57 ` Samuli Suominen
2013-08-01 23:15 ` Rich Freeman
2013-08-02 3:04 ` Dale
2013-08-02 8:15 ` Michał Górny
2013-08-06 0:32 ` Rick "Zero_Chaos" Farina
2013-08-11 14:59 ` Ulrich Mueller [this message]
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=20999.42712.964581.102162@a1i15.kph.uni-mainz.de \
--to=ulm@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