DragonFly kernel List (threaded) for 2003-08
On Saturday 02 August 2003 10:50 pm, you wrote:
> 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
> > 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
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.
chip norkus; renaissance hacker; wd@xxxxxxxx
"question = (to) ? be : !be;" --Shakespeare http://telekinesis.org/