From owner-freebsd-arch Mon Jul 8 15:15:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 230D737B400 for ; Mon, 8 Jul 2002 15:15:40 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F1D743E4A for ; Mon, 8 Jul 2002 15:15:39 -0700 (PDT) (envelope-from DougB@FreeBSD.org) Received: from zoot.corp.yahoo.com (zoot.corp.yahoo.com [216.145.52.89]) by mrout2.yahoo.com (8.11.6/8.11.6/y.out) with ESMTP id g68MFCR22064; Mon, 8 Jul 2002 15:15:12 -0700 (PDT) Received: from localhost (dougb@localhost) by zoot.corp.yahoo.com (8.12.5/8.12.5/Submit) with ESMTP id g68MFCw5084723; Mon, 8 Jul 2002 15:15:12 -0700 (PDT) Date: Mon, 8 Jul 2002 15:15:12 -0700 (PDT) From: Doug Barton To: Terry Lambert Cc: arch@FreeBSD.org Subject: Re: Package system flaws? In-Reply-To: <3D295B77.E62ED5FC@mindspring.com> Message-ID: <20020708150549.D84324-100000@zoot.corp.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 8 Jul 2002, Terry Lambert wrote: > Metadata is metadata. For sufficiently broad definitions of metadata, ok. > If it's good to put metadata in a file seperate from the data it > describes, then the judgement of "goodness" is universal. This I disagree with. Insert obligatory quote about "foolish consistency." > We do this because it makes the data and metadata non-severable, See a later post by me on this thread where I clearly state severability as a specific, and desirable goal for this application. > it relieves us of having to consider synchronization issues which > would otherwise arise, and we do it because it's convenient in > terms of speed of operations involving both, and convenient in > terms of locality of reference. In this case, I think that the costs of synchronization are very small, and easily addressable by existing tools. Whereas, the benefits of severability are very great, and easily offset the costs of both not keeping them together, and the cost of actually performing and maintaining the severance. > It also gets rid of the implied graph edge for locking of data and > metadata, which can lead to an undetectable deadly embrace deadlock . I agree that this is a factor we need to keep an eye on. However, I think that the problem space is sufficiently small that we'll easily pass the 90/10 rule, and may even get as high as 95/5 with little additional effort. > All of these arguments apply equally well to bundling package > metadata with package data: conceptually, that metadata is no > different than file ownership, flags, or permissions. And here is where we would need to actually define which metadata we're considering splitting out where. I think dependancy data is a slam dunk for being split out into a seperate file, both because it's already been identified as something we need to know before we download the whole binary package, and because it is rather likely to change independent of the actual binaries themselves. I'm studiously trying to avoid focusing on implementation details because I'd like to spend some more time discussing the problem space, but if it'll help us understand the problems better, I could describe what I have in mind in a little more detail.... Doug -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message