On 2004-02-06, Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote: > On Fri, 6 Feb 2004 09:32:54 +0100 > Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > Maybe my wording was a bit too harsh. But I cannot see the point of > > offering the user the option of replacing his passwd/fstab/group with > > one that with 99% certainty is wrong > It is for sure "wrong" in sense that you can't blindly replace your own > file with the default one. But this doesn't mean that it doesn't worth > a merge: when a change is made to the standard fstab, it often for some > good reasons, like adding /dev/shm some time ago (if i remember > correctly), and this is something that user must know and it is the only > way to tell him (remember that people don't see einfos from ebuilds). [...] > So imo, all of this is not about "offering the user the option to > replace his custom files", but about informing him of important changes > he should apply. Now, the corollary is that this file should only be > updated for changes important enough to worth a merge. [...]
Of course, what you *really* want is to do a 3-way merge involving the "new install" config file, the "previous install" config file, and the actual config file that the user has determined they want. There is nothing fundamentally difficult in supporting this type of behaviour, but it would need some changes to how emerge installs things in config protected areas. (Anything that changes between releases would then show up as a possible "patch" to the real file.) Off the top of my head, you could do it by keeping the most recent "built" version of a config file rather than deleting it as part of the etc-update (stuff it in a subdirectory called ".baseversion" or some such - this has the added benefit that if you screw up a config file you have a backup of a "default one"). Just a (very rough) thought. phil -- change name before "@" to "phil" for email -- [EMAIL PROTECTED] mailing list
