From owner-freebsd-current@FreeBSD.ORG Wed Jul 16 14:44:11 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBB7637B401; Wed, 16 Jul 2003 14:44:11 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECBBD43F85; Wed, 16 Jul 2003 14:44:10 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.9/8.12.6) with ESMTP id h6GLiAVI094885; Wed, 16 Jul 2003 14:44:10 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9/8.12.6/Submit) id h6GLiAjT094884; Wed, 16 Jul 2003 14:44:10 -0700 (PDT) Date: Wed, 16 Jul 2003 14:44:10 -0700 (PDT) From: Matthew Dillon Message-Id: <200307162144.h6GLiAjT094884@apollo.backplane.com> To: Garance A Drosihn References: <200307161941.h6GJfXbA093990@apollo.backplane.com> <3F15BA2C.9000503@FreeBSD.org> cc: current@freebsd.org cc: kernel@dragonflybsd.org Subject: Re: Annoucning DragonFly BSD! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2003 21:44:12 -0000 :> :> I stupidly misspelled 'announcing' in the subject line, : :Well, at least you didn't misspell your name... :-) : :> but it's very real. Check the site out: :> :> http://www.dragonflybsd.org/ : :The site looks interesting. All the kernel-level stuff is :pretty much over my head, but I will be interested in the :package-level ideas (once work starts on that part). : :-- :Garance Alistair Drosehn = gad@gilead.netel.rpi.edu I have the beginnings of an idea for how to do the packaging stuff properly... and how to automated it so one gets the dependancies correct. To realize the idea I will have to get to the point where a VFS layer can run in userland. Then it becomes trivial to build 'filtering VFS layers' that run in userland (i.e. don't take up kernel resources) which can be used to figure out *exactly* what a package references in the system and *exactly* what it effects. Once one is able to do that the dependancy and conflict information can not only be completely automated, but one can theoretically (and automatically) create 'environments' for each package to run in which resolve the conflicts (i.e. makes sure that the exact version of third party shared libraries and so forth used by a package are the ones that package sees even if multiple versions would normally install over each other). I'm guessing 6 months until the project gets to that point, oweing to the complexity of fixing VFS and, in particular, VFS_LOOKUP. But then, watch out! Infinite application... not only to the packaging system, but to the concept of how jails should work as well, and many other things. -Matt