Date: Sun, 07 Jul 2002 15:20:28 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Dag-Erling Smorgrav <des@ofug.org> Cc: Doug Barton <DougB@FreeBSD.org>, Dan Moschuk <dan@FreeBSD.org>, arch@FreeBSD.org Subject: Re: Package system flaws? Message-ID: <3D28BEAC.4A5BA84@mindspring.com> References: <20020706220511.GA88651@scoobysnax.jaded.net> <3D27A296.D58FB4B4@softweyr.com> <xzplm8nrgse.fsf@flood.ping.uio.no> <20020707153457.GA1086@scoobysnax.jaded.net> <3D28AF72.8F14DC40@FreeBSD.org> <xzpznx3mdm6.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smorgrav wrote: > Doug Barton <DougB@FreeBSD.org> writes: > > What is it about working on ports that makes people automatically > > gravitate to the most hideous, complicated solutions? Why not just > > create a tarball with the stuff to install, create the metadata file (in > > whatever format), then create a tarball with the two together? Then, > > step one is to unroll the tarball, read the metadata, grab dependencies > > if needed, then proceed to do the rest of the install. > > We want to be able to install a package from a non-rewindable source > without storing a temporary copy on disk. This means the metadata > must without fail be at the very beginning of the package. I think you just want lookahead, actually. HTTP and FTP are both rewindable; the expense is relative to the server, but FTP supports "reget" and HTTP supports range requests. 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. 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. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D28BEAC.4A5BA84>