From owner-freebsd-arch Mon Jul 8 18:38:44 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 24B7C37B400; Mon, 8 Jul 2002 18:38:39 -0700 (PDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C37D043E42; Mon, 8 Jul 2002 18:38:38 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0460.cvx22-bradley.dialup.earthlink.net ([209.179.199.205] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17Rjxd-00057N-00; Mon, 08 Jul 2002 21:38:37 -0400 Message-ID: <3D2A3E73.8A6BFA16@mindspring.com> Date: Mon, 08 Jul 2002 18:37:55 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Doug Barton Cc: arch@FreeBSD.org Subject: Re: Package system flaws? References: <20020708150549.D84324-100000@zoot.corp.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Doug Barton wrote: > > 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. Insert obligatory quote about "1 0wn y00r b0x". 8-). I don't understand your severability argument. Or maybe I just disagree with it at such a fundamental philosophical level that it just seems like I don't understand it. > 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. I give: What are the benefits of having to downlaod multiple files, rather than a single file, via HTTP protocol? > > 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. The current code partially solves the problem. If 90/10 is OK, then the problem is solved, and we can quit discussing it, as 90% of the direct needs of people are satisfied already, I think. > > 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. OK, you need to clarify what you mean by "file". Do you mean "archive content element", or do you really mean *file", as in "down load this archive *file* and download this metadata *file* seperately, and hope nothing gets lost or outdated". > 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.... OK. But be aware that we may have different ideas of the problem space... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message