Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Jun 2006 08:49:56 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        "Greg 'groggy' Lehey" <grog@freebsd.org>
Cc:        Tom Rhodes <trhodes@freebsd.org>, src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org
Subject:   Re: HISTORICAL_MAKE_WORLD (was: cvs commit: src Makefile README)
Message-ID:  <200606120849.57695.jhb@freebsd.org>
In-Reply-To: <20060610005707.GK7549@wantadilla.lemis.com>
References:  <200606070333.k573XmRc067920@repoman.freebsd.org> <200606090853.48604.jhb@freebsd.org> <20060610005707.GK7549@wantadilla.lemis.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 09 June 2006 20:57, Greg 'groggy' Lehey wrote:
> On Friday,  9 June 2006 at  8:53:47 -0400, John Baldwin wrote:
> > On Wednesday 07 June 2006 20:48, Greg 'groggy' Lehey wrote:
> >> On Wednesday,  7 June 2006 at 10:51:45 -0400, John Baldwin wrote:
> >>> I thought the obfuscation was intentional as very few people should
> >>> be doing a 'make world' without a custom DESTDIR these days.
> >>
> >> Then there's no reason not to document it.
> >>
> >>   Warning: FORCE_ROOT_INSTALL can render your system unusable by
> >>   overwriting existing configuration files.  Do not use it unless you
> >>   are completely aware of the consequences.
> >>
> >> And yes, a descriptive name like FORCE_ROOT_INSTALL, not
> >> HISTORICAL_MAKE_WORLD.
> >
> > Describing it would subvert the intended obfuscation.
> 
> s/subvert/correct/
> 
> Obfuscation is always wrong.

Not in this case.

> >> The only justification for this regression is that it's really
> >> difficult to get everything right.  But that's a bug, not a
> >> feature.
> >
> > No, the justification is that 'make world' completely ignores the
> > kernel and only handles userland, and an operating system is both a
> > kernel and a userland and that users should update those together.
> 
> That's a bug in make world.  Introducing a second one doesn't fix it.

The bug was fixed by the 'buildworld / buildkernel / installkernel / 
installworld' process that we now use.  The bug is fundamental to the way 
that make world works and you can either change how make world works or you 
can require no ABI changes in the kernel <-> userland interface.  We chose to 
change how make world works.

> > If you as a developer want to use make world you can either run the
> > two commands back to back or you can put
> > I_REALLY_KNOW_WHAT_IM_DOING_AND_WANT_TO_HOSE_MY_MACHINE in make.conf
> > or something.  However, developers wanting to do this are in the
> > _VAST_ minority and I'd much rather cater to the other 99% of the
> > world.
> 
> As I say,
> 
> >> The only justification for this regression is that it's really
> >> difficult to get everything right.
> 
> Otherwise people would have fixed it.

No, you aren't reading what I'm saying.  The justification is a _fundamental_ 
_design_ FLAW in how 'make world' works.  You can't just patch around that.  
You can't force 'make world' to boot up a new kernel for you that will work 
with the new userland you are about to install.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200606120849.57695.jhb>