Synergy

[Chip Norkus]

On Saturday 02 August 2003 10:50 pm, you wrote:

[snip]
>
> Oh, quite true.  Wherever I wrote "CVS", instead substitude "whatever
> revision control the system is under".  But then you have to make sure
> your merging tool knows what that is, how to access it...   heck, maybe
> how to access MULTIPLE ones!  What if The System (tm) is in CVS, but
> you locally mirror it into Subversion or something?  This could
> snowball really fast.
>

Which is why the tool should be independent of your SCM completely.

> > 1) Install your system.  Part of your system is the 'passwd' package
> > which comes with stuff like the pw util, ch* utils, /etc/passwd and
> > /etc/group files, and maybe some other stuff.  When the package gets
> > installed it stores some kind of snapshot of /etc/group and
> > /etc/passwd (maybe just an md5 sum, maybe an actual copy of the
> > file).
>
> I think it'd have to be the latter.  The former doesn't give us too
> much gain over what we already have (it gives some, of course, since
> the merger can know "it's been modified", but if we're gonna bite this
> bullet, we might as well bite all the way through at once).
>

Well, I think some people are going to want to merge things by hand.  I 
also think that it's going to be a very useful first step.  Getting the 
full functionality of the save-and-merge working isn't going to be 
simple, and at some point there's going to have to be a merge-by-hand 
request anyways.

> > And maybe if this was a particularly smart or configurable program
> > you could tell it, before it starts installing packages, which
> > behavior you'd prefer.
>
> And before anybody else says it, what we REALLY want is a versioning
> filesystem!  Yeah!  And files like this should have a vendor branch
> where the 'upgrades' go!
>

Nah.  I don't think that much work is necessary.  It would be cool, of 
course, but not per se required I don't think.  On the other hand I think 
one of Matt's (Dillon rather) ideas was to do something not unlike this, 
so that a filesystem might have many layers corresponding to a package 
installation so that two copies of the same file, when accessed by 
programs from different packages could exist simultaneously and 
more-or-less transparently.

The only problem with this is that the current crop of file tools are 
grossly incapable of handling anything like this, and that people 
themselves are going to need to perform a pretty significant mental shift 
to handle this kind of system.

Or maybe I didn't understand the idea at all. :)

> > Yes, this is where it gets tricky.  When people update their world
> > (base system) outside of the realm of the packaging tool.  I think if
> > that is
>
> Every time you look at the durn thing, the problem gets bigger   8-}

Well, not necessarily.  If you take what I said about making world builds 
just a set of package-from-source builds then this doesn't complicate the 
issue too much.  As long as you make this the only supported method, 
anyways.  I think what's important is that you take an issue like "from 
source installs" and say "okay, you can do this, but it's outside the 
bounds of the package manager and so we're not going to make a Herculean 
effort to support it."  If people want to install things from source, 
then they're just not going to get package management support.  For 
example if you want to install X by hand, that's fine, but when you 
upgrade foo and foo depends on a certain version of X it is up to you to 
make sure you've updated X.

-wd
-- 
chip norkus; renaissance hacker;                wd at xxxxxxxx
"question = (to) ? be : !be;" --Shakespeare     http://telekinesis.org/