Date: Mon, 08 Jul 2002 16:08:39 -0700 From: Wes Peters <wes@softweyr.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Dag-Erling Smorgrav <des@ofug.org>, Doug Barton <DougB@FreeBSD.org>, Dan Moschuk <dan@FreeBSD.org>, arch@FreeBSD.org Subject: Re: Package system flaws? Message-ID: <3D2A1B77.AF0678FC@softweyr.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> <3D28BEAC.4A5BA84@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D2A1B77.AF0678FC>