ivoras at freebsd.org
Sat Jan 3 03:55:28 UTC 2009
2009/1/3 Doug Barton <dougb at freebsd.org>:
> Garrett Wollman wrote:
>> <<On Fri, 02 Jan 2009 14:15:20 -0800, Doug Barton <dougb at FreeBSD.org> said:
>>> As I said in my first post, if there is overwhelming demand for this
>>> down the road that is not met by the existing solutions I'll consider
>>> adding a better implementation as an option, off by default.
>> It would be much better if the options that *nearly every user will
>> want to use* are set correctly by default.
> 1. Past experience indicates that your average _developer_ is not very
> good at estimating what the average _user_ will want as the default.
> 2. The needs of developers are considerably different than the needs
> of the average user.
And just how can upgrading all the non-user-modified files cause
serious damage here (serious=system not bootable, login not possible,
etc)? Please explain with examples, since from this and the old
current@ thread I only got the impression that "it's baaaad, m'kay".
Note that regular users will not upgrade -CURRENT, and most won't even
upgrade -STABLE, but will go from one -RELEASE to another. Speaking
for myself, mergemaster is a source of constant irritation because it
doesn't do auto-upgrades by default, and I'm often tempted to just not
start it rather than going through 15 minutes of "q, i, <enter>" (my
pages is less, thus the "q").
If you're so against this option, may I propose something that could
satisfy both camps: make a symlink to mergemaster, call it
"auto-mergemaster", detect the called name from within the script,
then enable autoupgrades if it matches "auto-mergemaster" (as well as
possibly other features that make it less verbose and less user-input
intensive). Do this as a service to the community and create yourself
the possibility of telling us "I told you so"!
I'm pretty much sure that users will eventually forget there's a
manual "mergemaster" but it will still be available for users used to
the old semantics. Your response, please?
> 4. I have said literally from day 1 that mergemaster should not ever
> change a file on a user's system without them taking an affirmative
> step for it to do so. Whether you agree with that idea or not, it is
> an expectation that I do not want to mess with.
Please consider that the user climate has changed from "day 1".
> Given the number of help requests I get for mergemaster that are
> already answered in the man page, I do not regard this as all that big
> of a problem. :) But seriously folks, have you read all the way down
> to the part about the ability to use an rc file to store your commonly
> used options?
Thanks for this, I didn't know about the rc file, but I see two
problems with it:
1) The example in the man page doesn't say how to enable "-U" mode
(reading on 7.1-stable)
2) This means I have to copy yet another file to my newly installed
systems, and I think I'm not the only one who does this and would like
to avoid another file. I install new systems from CDs fairly often,
and the list currently includes about a dozen files (tcsh rc files,
cvsup files, vim rc, etc.).
More information about the svn-src-head