[gentoo-project] Support for Seperate /usr

[gentoo-project] Support for Seperate /usr

[Rich Freeman]

Splitting thread so that the agenda thread isn't lost in discussion:

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.

Rich

Re: [gentoo-project] Support for Seperate /usr

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1201 bytes --]

Am Donnerstag, 1. August 2013, 23:16:26 schrieb Rich Freeman:
> 
> 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.
> 

1) I have some doubts that this is really "under control". Maybe someone from 
base-system should comment how well booting with separate usr AND without 
early boot mechanism works. (That's also where Diego's blog posts come in.)

2) The main difficulty is that last council decided "something" and everyone 
has a different opinion on what was actually decided.

3) If things are not "under control", no council decision will magically fix 
that.

4) We should also remind ourselves that the general Gentoo philosophy used to 
be "follow upstream as much as possible". Given the general direction in Linux 
outside Gentoo, more and more software may migrate into /usr. Do we want to 
step up patching?

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-project] Support for Seperate /usr

[William Hubbs]

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

On Thu, Aug 01, 2013 at 05:16:26PM -0400, Rich Freeman wrote:
> 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.

The whole reason I brought this up is, according to some, the council
did step in in April of 2012 and mandate that we must support separate
/usr without an early boot workaround. If you read the meeting log from
that meeting, it seems pretty clear that was chainsaw's intent.

Because of that perception, if base-system decides to do something
differently, there would definitely be flack over it.

In a nutshell, I am asking the council this question:

Is separate /usr, without an early boot mechanism like an initramfs,
an officially supported configuration?

William


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

Re: [gentoo-project] Support for Seperate /usr

[Samuli Suominen]

On 02/08/13 01:49, William Hubbs wrote:
> On Thu, Aug 01, 2013 at 05:16:26PM -0400, Rich Freeman wrote:
>> 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.
>
> The whole reason I brought this up is, according to some, the council
> did step in in April of 2012 and mandate that we must support separate
> /usr without an early boot workaround. If you read the meeting log from
> that meeting, it seems pretty clear that was chainsaw's intent.
>
> Because of that perception, if base-system decides to do something
> differently, there would definitely be flack over it.
>
> In a nutshell, I am asking the council this question:
>
> Is separate /usr, without an early boot mechanism like an initramfs,
> an officially supported configuration?
>
> William
>

The work can continue separating / vs. /usr deps still -- I've just done 
that for libusb, libusbx, libusb-compat using `gen_usr_ldscript -a` from 
toolchain-funcs.eclass

Then gen_usr_ldscript could be converted to no-op, or at least gain 
environment variable like USR_MOVE="yes" in which case nothing is moved 
to / and it's really no-op.

This was just discussed today at end of this bug 478878

So let's keep the work going if someone requests, but lets convert 
gen_usr_ldscript optional

Re: [gentoo-project] Support for Seperate /usr

[Rich Freeman]

On Thu, Aug 1, 2013 at 6:49 PM, William Hubbs <williamh@gentoo.org> wrote:
> The whole reason I brought this up is, according to some, the council
> did step in in April of 2012 and mandate that we must support separate
> /usr without an early boot workaround. If you read the meeting log from
> that meeting, it seems pretty clear that was chainsaw's intent.
>
> Because of that perception, if base-system decides to do something
> differently, there would definitely be flack over it.

I understand that completely.  However, I'd only like to step in if
base-system actually plans to do something and is concerned about
there being flack over it.  If they don't care to change anything then
no action is needed.  If they plan to change things but don't care
about hearing people complain, then no action is needed.  If I took
action it would only be to tell them they can do whatever they want to
as long as an initramfs still works (or whatever other workarounds
people come up with) - I'd just prefer to only step in if somebody
feels there is a need.

Right now the only argument I'm hearing is that we need to clarify
what the policy is because the policy is unclear and lack of clear
policy bothers some people.  I'm not hearing why we care about there
being a policy in the first place.  If somebody just states "I'm doing
a lot of extra work because I feel like I have to, so please tell me
that I don't have to" then I'm fine with stepping in.

Rich

Re: [gentoo-project] Support for Seperate /usr

[Rich Freeman]

On Thu, Aug 1, 2013 at 5:42 PM, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
> Am Donnerstag, 1. August 2013, 23:16:26 schrieb Rich Freeman:
>>
>> 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.
>>
>
> 1) I have some doubts that this is really "under control". Maybe someone from
> base-system should comment how well booting with separate usr AND without
> early boot mechanism works. (That's also where Diego's blog posts come in.)

To clarify - I mean that things are under control in the sense that
nobody on base-system besides williamh seems to really care about
having the decision clarified.  I agree completely with Diego's
assessment/etc.  Today a system with a separate /usr and no
initramfs/etc generally works, but sometimes does not.

>
> 2) The main difficulty is that last council decided "something" and everyone
> has a different opinion on what was actually decided.

The thing is that I've yet to see any actual difficulty come up.  If
the udev team moved everything to /usr and there was an uproar and QA
told them that they consider it a violation, then I'd cal that an
actual difficulty (in which case I'd tell the udev team that they
don't have to worry about it as long as they don't break
genkernel/dracut/busybox/whatever).

>
> 3) If things are not "under control", no council decision will magically fix
> that.

I mainly advocate laissez faire on this issue, so from my standpoint
there really is nothing to fix unless some maintainer is being given a
hard time.  That is something the council definitely can fix, because
devrel isn't going to counter a council decision, and even if they did
they can be appealed - the rest is just hot air.

>
> 4) We should also remind ourselves that the general Gentoo philosophy used to
> be "follow upstream as much as possible". Given the general direction in Linux
> outside Gentoo, more and more software may migrate into /usr. Do we want to
> step up patching?

Yup.  If we're going to patch it seems like a better move to just
patch things the other way and do the /usr move so that there is at
least some kind of larger benefit from the change.  That's why I think
the whole "is separate /usr without an early boot mechanism a
supported configuration" bit is a bit of a sideshow.  I'm happy to
settle it if somebody wants us to, but if nobody cares then we're
basically making policy for the sake of having policy.  I'd rather see
us look beyond this and decide where we want to be.  To me the only
logical choices are FHS or /usr move, and to strictly follow the
former is slowly turning into just sticking everything in / -
something that shouldn't make sense to anybody.

Bottom line is that I'm happy to render a clear decision if anybody
really will benefit from having one, but I think the bigger picture is
that we should focus less on what we don't support and focus more on
what we do support.

Rich

Re: [gentoo-project] Support for Seperate /usr

[Dale]

Rich Freeman wrote:
> On Thu, Aug 1, 2013 at 6:49 PM, William Hubbs <williamh@gentoo.org> wrote:
>> The whole reason I brought this up is, according to some, the council
>> did step in in April of 2012 and mandate that we must support separate
>> /usr without an early boot workaround. If you read the meeting log from
>> that meeting, it seems pretty clear that was chainsaw's intent.
>>
>> Because of that perception, if base-system decides to do something
>> differently, there would definitely be flack over it.
> I understand that completely.  However, I'd only like to step in if
> base-system actually plans to do something and is concerned about
> there being flack over it.  If they don't care to change anything then
> no action is needed.  If they plan to change things but don't care
> about hearing people complain, then no action is needed.  If I took
> action it would only be to tell them they can do whatever they want to
> as long as an initramfs still works (or whatever other workarounds
> people come up with) - I'd just prefer to only step in if somebody
> feels there is a need.
>
> Right now the only argument I'm hearing is that we need to clarify
> what the policy is because the policy is unclear and lack of clear
> policy bothers some people.  I'm not hearing why we care about there
> being a policy in the first place.  If somebody just states "I'm doing
> a lot of extra work because I feel like I have to, so please tell me
> that I don't have to" then I'm fine with stepping in.
>
> Rich
>
>

As a user, I to would like this clarified.  I would like a clear
statement as to whether a separate /usr without init* is supported or
not.  No tap dancing around the issue, just a clear decision or a
statement as to what the prior decision was.

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-project] Support for Seperate /usr

[Michał Górny]

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

Dnia 2013-08-01, o godz. 22:04:36
Dale <rdalek1967@gmail.com> napisał(a):

> Rich Freeman wrote:
> > On Thu, Aug 1, 2013 at 6:49 PM, William Hubbs <williamh@gentoo.org> wrote:
> >> The whole reason I brought this up is, according to some, the council
> >> did step in in April of 2012 and mandate that we must support separate
> >> /usr without an early boot workaround. If you read the meeting log from
> >> that meeting, it seems pretty clear that was chainsaw's intent.
> >>
> >> Because of that perception, if base-system decides to do something
> >> differently, there would definitely be flack over it.
> > I understand that completely.  However, I'd only like to step in if
> > base-system actually plans to do something and is concerned about
> > there being flack over it.  If they don't care to change anything then
> > no action is needed.  If they plan to change things but don't care
> > about hearing people complain, then no action is needed.  If I took
> > action it would only be to tell them they can do whatever they want to
> > as long as an initramfs still works (or whatever other workarounds
> > people come up with) - I'd just prefer to only step in if somebody
> > feels there is a need.
> >
> > Right now the only argument I'm hearing is that we need to clarify
> > what the policy is because the policy is unclear and lack of clear
> > policy bothers some people.  I'm not hearing why we care about there
> > being a policy in the first place.  If somebody just states "I'm doing
> > a lot of extra work because I feel like I have to, so please tell me
> > that I don't have to" then I'm fine with stepping in.
> >
> > Rich
> >
> >
> 
> As a user, I to would like this clarified.  I would like a clear
> statement as to whether a separate /usr without init* is supported or
> not.  No tap dancing around the issue, just a clear decision or a
> statement as to what the prior decision was.

I agree here. Without a clear decision we can't properly tell users
what to do. If it's going to be not supported, we shall encourage them
(via a news item, likely) really much to update their computers.

This is some serious work that needs time to be done and user would
prefer knowing early and not whenever one of the devs decides not to
support it anymore. Non-booting system is not a good news, and unclear
policy shouldn't be an excuse for this.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-project] Support for Seperate /usr

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/01/2013 05:16 PM, Rich Freeman wrote:
> Splitting thread so that the agenda thread isn't lost in discussion:
> 
> 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).
dozens of things have randomly been moved from /usr to / as a result
strictly of user complaints.  For instance bzip2 was moved to / but
lbzip2 is in /usr which means I can't safely do something like "eselect
bzip2" and use a properly threaded bzip2 implementation.

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSAEQuAAoJEKXdFCfdEflKP5gP/jxr4FopH8XD6KPUctt7BH3/
y99DzXOFNmCFUC5AnYpkUW8XUchQv2e0Ti+OLAaTLHtvL8h2dfbQn58mDToqQGq0
Z/ifB3Pk4R31G8OzA1JL7NsQjJR3fgVALzlmD1nv7W43Jr4mMrvQtAkMbcYcDKzc
14RDkCMiewm+AAqQ6DWSuD+GM07lXw5y3aDp0vfGzgKQ2GVOXHsY77WIRFLveMrD
rWRKu8xt7WZ+t4DBl3uQm7mz0khvJnY4B1cY7SSlog8QnrXxM9ofU63RJ740MeUb
K72eWvjM/ZKbkpkjiMDKILNnuEwgCWsRXviO8DSNv1NqkQM3GkX84rMYJvtxIFSD
aYZQ9wTK7kN6gwjcH4/0zBi1xYG1krwd+sakRUsmxeMNuLgZixTa16WuB5Shfzrs
KhzfANPQAWKGchEMQlP4AJT4GyMLFhP8xe5Q6MdYesduK8GP/DQhC3xsJBzRXC7C
qUCN+5Y9Ub7Z+BWAPObW9e1fMzyiwwKLfunepkVIOYwYZsUyxfQYAMfM7VFLqtDU
x1YG9cZArPRcZJdn8LFe82o9DCyUUpaXviEePY6y+aZ+gPNWXEoBuyiiznMsXj17
T89JjJb4R74CDUniGGqKAqKqCaivm6FmUH7B11fEPe/1oEbcRUEoKDHIVxn362oy
CP8r+XZhTp5dxYplwMqh
=BGXp
-----END PGP SIGNATURE-----

Re: [gentoo-project] Support for separate /usr

[Ulrich Mueller]

[-- 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 --]