From owner-freebsd-arch Mon Jul 8 16: 4:51 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 45F8D37B400; Mon, 8 Jul 2002 16:04:48 -0700 (PDT) Received: from softweyr.com (softweyr.com [65.88.244.127]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3EDE43E3B; Mon, 8 Jul 2002 16:04:47 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from nextgig-5.customer.nethere.net ([209.132.102.165] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 17RhYa-0000nF-00; Mon, 08 Jul 2002 17:04:36 -0600 Message-ID: <3D2A1B77.AF0678FC@softweyr.com> Date: Mon, 08 Jul 2002 16:08:39 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Dag-Erling Smorgrav , Doug Barton , Dan Moschuk , arch@FreeBSD.org Subject: Re: Package system flaws? References: <20020706220511.GA88651@scoobysnax.jaded.net> <3D27A296.D58FB4B4@softweyr.com> <20020707153457.GA1086@scoobysnax.jaded.net> <3D28AF72.8F14DC40@FreeBSD.org> <3D28BEAC.4A5BA84@mindspring.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 Terry Lambert wrote: > > Putting the metadata up front resloves the issue of downloading > data you don't want, and also resolves the problem of being able > to collect all the metadata at the start, so that you can make > accurate time estimates, and the user can make a time-cost-basis > decision on whether or not to go ahead. > > Modern transfer protocols argue in general for a new archive format > that collects the metadata at the start of the archive to permit > such decisions to be made. > > From a general perspective, archives need to be able to be nested > recursively, and to be extracted recursively. Obviously, this is a > control mechanism enabling requirement: full extraction as a > default is necessary for "bootstrap", and selective extraction is > necessary as a component/function/customization selection method. The more you write, the more I see XML as being terribly appropriate for the package metadata. Consider the nesting problem; XML handles this with complete grace if you write it into the DTD that a package can contain a package. > Also from a general perspective, it needs to be possible to blindly > extract archives for "bootstrap" purposes: a bind extraction of an > archive from a current directory of "/" needs to result in not only > installation of the package contents in the correct default location, > but also in correct registration of those contents into the system, > minimally for one archive... but ideally for "n" archives... until a > more complete tools system has been bootstrapped. > > If you guys all want to think about something, think first about the > issues surrounding bootstrapping, and second, about the issues that > surround update and failure recovery, since they are the most critical > and least well supported by the current tools. Please give more detail about failure recovery, this is an important point and I'm not certain you mean what I mean when I think of pkg_add failure recovery. I generally worry about the atomicity of the operation; I either want all of the package I've asked for or none of it. As far as the bootstrapping issue, I'd like to see, at a minimum, pkg_add depend ONLY on libraries that are a "normal" part of the FreeBSD system. If this means we have to add a library or two to the base system, we'll make that argument when it is needed. I know all the arguments for something like pkg_add to use other executable system tools to remain in sync with them, but I'd rather see such tools (like tar) written as programs that call the same library as pkg_add. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message