Date: Sun, 24 Mar 2002 18:05:01 -0700 (MST) From: "M. Warner Losh" <imp@village.org> To: ryand-freebsd@ZenSpider.com Cc: cjc@FreeBSD.ORG, randy@psg.com, dima@trit.org, freebsd-stable@FreeBSD.ORG Subject: Re: mergemaster mtree:No such file or directory Message-ID: <20020324.180501.53140478.imp@village.org> In-Reply-To: <20020324163351.A73171@greed.zenspider.com> References: <6E639CB8-3F7E-11D6-B638-0030655293B0@zenspider.com> <20020324154542.B82432@blossom.cjclark.org> <20020324163351.A73171@greed.zenspider.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20020324163351.A73171@greed.zenspider.com>
Ryan Davis <ryand-freebsd@ZenSpider.com> writes:
: On 2002-03-24T15:45:42, Crist J. Clark wrote:
:
: > > Shouldn't the build system (including mergemaster) be impervious to
: > > side-effects from things like PATH?
: >
: > I could easily envision situations where one might want to play games
: > with one's PATH when using mergemaster(8). I think having
: > mergemaster(8) toss aside the user's PATH and essentially hardcode its
: > own makes the tool much less flexible, violates POLA, and generally
: > violates the whole purpose of PATH and environmental variables.
:
: Call me wacky, but "play games when using mergemaster" == command line
: option in my book. Good Configuration Management would probably state
: that the build and configuration tools should do the same thing every
: time regardless of how wonky my environment is. Only when I say "no no
: mergemaster, this is a special case" should it act outside the norm.
:
: Translation: the rest of us should have repeatable results across ALL
: of our systems.
:
: I think taking this step (for all of the build systems, including
: ports) would be a GoodThing. It would help the 90% case quite a bit
: and probably quiet the mailing list too. I've seen weird cases lately
: where the solution to some poor fool's port building problem is "Take
: '.' out of your path". That's just NOT going to help us increase the
: usability of our favorite OS, is it? We should do everything in our
: power to make stable and ports and clean and usable as possible.
Personally, I'd rather see most of mergemaster be a three way merge,
rather than how it is done now. Meaning that you have some base
FreeBSD version. This gets checked into CVS (or some other scm), that
I'll call the local repo. The user hacks on it and installs files
that are then committed back into local repo. Time passes, you do an
upgrade. mergemaster does a cvs diff -u -r base-version -r HEAD on
each of the files on the FreeBSD cvs repo and applies those diffs to
the local repo, allowing one to then install from there.
This works well for almost all the /etc files, except those that hold
passwords (like the opiekeys, master_password etc). Of course, you
could likely do this w/o the local repo, and apply the patches
directly to the /etc files (or to a copy that you then copy back).
One would then need to keep a database of versions, or mandate that
you can't remove $FreeBSD$ from the files. Patches that fail to apply
are then punted back to the user for resolution.
Warner
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020324.180501.53140478.imp>