Date: Fri, 5 Jul 2002 20:07:44 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Terry Lambert <tlambert2@mindspring.com> Cc: Paul Richards <paul@freebsd-services.com>, Sheldon Hearn <sheldonh@starjuice.net>, current@FreeBSD.ORG Subject: Re: Removing perl in make world Message-ID: <p05111736b94be16e068e@[128.113.24.47]> In-Reply-To: <3D261EA4.ABC3AEC@mindspring.com> References: <1025862341.1573.40.camel@lobster.originative.co.uk> <20020705095258.GC775@starjuice.net> <1025864161.1573.45.camel@lobster.originative.co.uk> <p05111730b94b6a140d74@[128.113.24.47]> <3D261EA4.ABC3AEC@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 3:33 PM -0700 7/5/02, Terry Lambert wrote:
>
>So, to summarize:
>
Let me summarize my own position.
There are a number of files which installworld does install. After
an installworld is done, there may be a number of files on a person's
hard disk which were not put there by the most recent installworld.
For each of those files, the issue is one of intent.
1) Is it there because the administrator explicitly wanted it
to be there, for explicit reasons that may be perfectly valid
even while testing the latest snapshot of current?
2) or is it left-over cruft from some previous install, and
which is only getting in the way of proper testing?
If you keep it that simple, instead of writing 200-line summaries
of what is going on (and the possible motivations of everyone), then
the solution is also simple. The above is just a slight variation
from what happens with /etc config files during a new installworld.
We should not have anything which automatically blows away those
files. We should have an "unmergemaster" script, which will find
those files, and **ASKS THE DEVELOPER** what they want to do for
each of those files (or maybe for each set of files). No automatic
process is going to be 100% right 100% of the time.
Developers do not need to have installworld forcing some person's
idea of what a "pristine" testing environment should look like.
However, it would be very useful to have something which would
just *tell* us what the difference is between our environment and
this imaginary perfect testing environment, so we can decide what
should (and what should not) be changed.
While the solution may be conceptually simple, I will admit that I
have no intention of working on it myself. I will therefore drop
out of the debate in this thread at this time. Not that I'm upset
about any of it, it's just that I don't think I have anything more
to contribute.
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05111736b94be16e068e>