DragonFly BSD
DragonFly kernel List (threaded) for 2003-08
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Synergy


From: "Matthew D. Fuller" <fullermd@xxxxxxxxxxxxxxx>
Date: Sat, 2 Aug 2003 21:41:02 -0500

On Sat, Aug 02, 2003 at 09:16:45PM -0500 I heard the voice of
Chip Norkus, and lo! it spake thus:
> On Saturday 02 August 2003 08:44 pm, Kurt B. Kaiser wrote:
> 
> [snip]
> >
> > To me, one of the key points about an OS is how well the package
> > management system works and how much time is going to be spent keeping
> > the system current with the errata.  I can understand why it's
> > necessary to drop support on older releases, but how easy is it to
> > upgrade to the next release and then keep it patched?  Right now too
> > much time is spent with mergemaster grovelling over /etc.  Why should
> > I have to merge passwd and group files because a system user or group
> > was added at the new release?  Why not have separate files for system
> > and user?
> >
> 
> Or why not have a more intelligent merge system that will handle tasks 
> like this for you?  I don't think you need to separate system and user 
> account spaces so much as you need a merge tool that will say "hmm, okay, 
> this is the standard configuration and this is what the user has added.. 
> there don't seem to be conflicts between the two, so let's merge them."  

The 'easy' answer to this is to have a mergemaster-like tool that
understands CVS.

Thus, if I change (for instance) root's GECOS info, or shell, or homedir,
the tool can pull out the revision I started with and the current
revision, compare those diffs with my diffs, and say "Hm, well, this line
is different in the working copy from the original...  but the current
version is no different than the original, so that must be a user change
I should preserve".  Or the similar step of diff'ing the working copy
against the original revision is started from, checking out the current,
then applying those user changes to the new version.


The difficulty with such schemes is that you either need to have the full
CVS repo around, or you need to create something like /var/backups/etc
with ALL the files in their untouched form, to use for comparison
against.  Then you need to keep that directory updated.  It raises the
bar a *LOT* for people using the program.

Now, having such a thing for differences between explicit versions is
relatively easy, since you could in some manner compile all that
knowledge into it.  But for the BSD Way (tm) of building and upgrading
the world at arbitrary points along a CVS branch, you couldn't
realistically have that kind of info available, without having a CVS
repository also available.



-- 
Matthew Fuller     (MF4839)   |  fullermd@xxxxxxxxxxxxxxx
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/

"The only reason I'm burning my candle at both ends, is because I
      haven't figured out how to light the middle yet"



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]