On Sat, Nov 17, 2012 at 08:02:07PM +0100, Fabian Groffen wrote:
> Handling separate /usr support
> ==============================
> WilliamH requested approval for two methods to support separate /usr
> systems[2]. The discussion is closely related to recent opinons on udev, such
> as e.g. [1], because the main reason to force a system without separate /usr
> during boot is to allow newer versions of udev to be used.
> The originally announced item of discussing the removal of gen_usr_ldscript
> has been retracted[4].
> - approve/disapprove plan (forcing everyone to take action, and
> implement one of the two "supported" solutions)
>
> WilliamH requests a council vote to allow migrating everyone after bugs
> [5,6,7] are resolved. He proposes a news item to announce this that allows to
> assume after a given period of time that everyone who is using split /usr is
> using a method to mount /usr before boot. The focus is purely on this topic.
>
> rich0 prefers to move on until suport for separate /usr becomes a
> barrier, and handle things from there. This allows for alternative
> solutions to be developed and put forward. He favours waiting somewhat
> to see developments of the udev fork.
>
> Chainsaw is a strong proponent for waiting a month and see how the new
> udev fork develops itself. If within a month no solution is provided by
> the udev fork, things need to be moved forward in WilliamH's proposed
> way.
>
> scarabeus approves the plan.
>
> betelgeuse likes to ensure users won't be caught off guard, but has no
> preference for any direction taken in particular.
>
> graaff's main concern is how the problem is tied to udev, or not. A fork of
> udev may not change the situation regarding separate /usr, hence delaying a
> decision now is not sensical. Opt-in system for people to ensure they can
> boot is pre-requisite. If this cannot be ensured, we have to wait.
>
> grobian disapproves the plan, since there will be systems that cannot easily
> be changed to ensure /usr being mounted at boot, and it is no good to expel
> users of (security) updates just because of that. With the use of a special
> profile (masks/unmasks, variables and/or use-flags), users that want to move
> on, can opt-in to getting packages that require non separate /usr.
So, that's a nice summary, but, what is the end result here?
I see an "entertaining" fork of udev on github at the moment (-ng,
really? What happens when someone wants to fork that, -ng-ng? Be a bit
more original in your naming please, good thing I never trademarked
"udev" all those years ago, maybe I still should...)
The commits so far in that repo are fun to watch for a variety of
reasons, none of which I should repeat hear less I get a bunch of people
mad at me :)
But, along those lines, what is the goal of the fork? What are you
trying to attempt to do with a fork of udev that could not be
accomplished by:
- getting patches approved upstream
or:
- keeping a simple set of patches outside of the upstream tree and
applying them to each release
I understand the bizarre need of some people to want to build the udev
binary without the build-time dependencies that systemd requires, but
surely that is a set of simple Makefile patches, right? And is
something that small really worth ripping tons of code out of a working
udev, causing major regressions on people's boxes (and yes, it is a
regression to slow my boot time down and cause hundreds of more
processes to be spawned before booting is finished.)
As I posted elsewhere, working on a project based on "hate" only lasts
so long. I should know, that's the reason I started udev in the first
place over 9 years ago[1].
You need to have a real solid goal in place in order to be able to keep
this up in the long-run. Otherwise you are going to burn yourself out,
and end up alienating a lot of people along the way.
Oh, and if _anyone_ thinks that changing udev is going to "solve" the
"no separate /usr without an initrd" issue, I have a bridge I want to
sell them.
thanks,
greg k-h
[1] Long story, best told over beers, take me up on it the next time you
see me, I'll buy.
