Re: [gentoo-project] rfc: separate /usr preparation vote

[William Hubbs]

On Sun, Aug 18, 2013 at 07:37:53AM -0400, Rich Freeman wrote:
> On Sun, Aug 18, 2013 at 2:32 AM, Ulrich Mueller <ulm@g.o> wrote:
> >>>>>> On Sat, 17 Aug 2013, William Hubbs wrote:
> >
> >>       The Council agrees that all preparations for dropping support
> >> for separate /usr without an initramfs or similar boot mechanism are
> >> complete.
> >
> > Why such a hurry? We have voted that we would "eventually" drop
> > support, and in the log you can find that we were talking about a
> > timeframe of six months.
> >
> > I suggest that we revisit the topic no earlier than in six months from
> > now.
>
> Personally I was thinking WITHIN the next six months, not taking no
> action for six months and then restarting the debate.
>
> I think williamh is perfectly within his rights to suggest that we're
> ready to go.  Anybody who has a problem with his suggestion is also
> within their rights to state a specific objection (something
> actionable).

Correct, there is no reason to wait six months just for the sake of
waiting six months. One bug was filed against the tracker and fixed
within hours.
 
> I just don't see any reason for waiting, at least not right now.  If
> the argument is that we should give users some period of time to
> prepare, then we should be sending out some kind of specific news item
> telling them what preparations to make and THEN waiting.

The vote is to make sure all of the necessary documentation is in place,
so this isn't really part of it. But, yes, once this vote passes,
communication to users as the changes happen will be important.

> If we think docs/etc are in place there are a few different positions
> we could take:
>
> 2.  We could ask that news be sent out before the first significant
> change to / and there be some time period before taking action on it.
> (ie, we trust maintainer discretion)

There aren't going to be that many maintainers involved in this (mostly
it is base-system and toolchain), so I think this is the best route to
take. We are not here to micromanage maintainers.

> 3.  We could ask that maintainers of packages in / get council
> approval for each move to /usr with at least brief justification and a
> proposed communication plan.  (ie, we don't trust maintainer
> discretion)

I think this would be a waste of time for maintainers and for us. Do we
really want to micro-manage this and have maintainers bring individual
packages to the council to get this type of approval?

> 4.  We could tell maintainers not to make deliberate changes without
> individual approval, but they could WONTFIX bugs that point out small
> regressions/etc without approval.  (ie let's not open the floodgates
> yet, but we can relieve some pressure on maintainers and let entropy
> take its course)

This is saying the same thing you said in #3. Don't do anything without
approval. and I'm against this because I don't think we should
micromanage.

> Here is my personal take:  The stated reason for dropping separate
> /usr support without an initramfs/etc is that this is a config that
> upstreams are steadily moving away from.  I get that, and I don't want
> maintainers to have to bend over backwards to keep it working.  That
> said, I also don't see a need to make huge overnight changes (if a
> maintainer thinks this is the only way to reduce their workload,
> please speak up).  I think that this should probably be handled like
> the kde4 transition, or the gnome-systemd transition.  That is, we
> provide a reasonable amount of support for the status quo until that
> state of affairs just isn't tenable.

The problem is, there already is subtile breakage in the status quo. for
example, anything that tries to read from /usr/share/* in early boot,
before /usr is mounted, is broken by definition, and any binary in /
that tries to link to a library in /usr/lib* too early will fail.

> If anybody feels we're already at the point where supporting the
> status quo is untenable by all means speak up.  I don't want to make
> maintainers work harder, but I also don't want to force changes
> earlier than necessary without some reason for it.

It is true that a lot of it is boiler plate (copy/paste), but we are
doing a lot of things with ebuilds to make /usr sort of work. There have
also been specific bugs in the past, requesting that we move packages to
/ to accomodate this separate /usr configuration that sort of works like
https://bugs.gentoo.org/show_bug.cgi?id=443710. Samuli was right on this
bug initially, but there was no decision from council to stand on, so
the folks who wanted it in / were able to push it through. Things like
this should be undone, and the way to do it is with initramfs.

Basically the status quo includes specific changes that were made in
our packaging to allow this sort of working separate /usr without
initramfs configuration to continue limping along, but we need to undo
them.

> That said, those who feel that we're not ready need to state a
> specific actionable objection.  "The docs aren't ready" isn't specific
> or actionable.  "The handbook should say xyz in this section" or "the
> dracut guide should specify that the usrmount module should be enabled
> if you have a separate /usr and how" are.
>
> Finally, I could see the /usr merge as a POSSIBLE reason to move
> things sooner.  If somebody wants to propose some plan to make that
> happen they should do so, and we can debate it on this list and so on.
>  However, I don't see any value in moving a bunch of stuff around
> purely for the sake of a /usr merge when there isn't any plan to
> finish the work.  If anybody is thinking about that being the driver
> they need to have a plan that actually gets us to the end goal, and of
> course we need to agree that this is even a goal we want to have.

The /usr merge is a totally separate issue that I really don't want to
bring into this discussion. There are people who are fine with us
cleaning up the separate /usr issue, but opposed to the /usr merge, so
that needs to be a separate item imo.

William