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 = [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Institute or [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
