Date: Mon, 23 Oct 2000 15:05:22 -0700 From: Jordan Hubbard <jkh@winston.osd.bsdi.com> To: kientzle@acm.org Cc: Alexander Langer <alex@big.endian.de>, libh@freebsd.org, "Jordan K. Hubbard" <jkh@freebsd.org> Subject: Re: BOF at BSDCon: FreeBSD Installer, Packages System Message-ID: <9947.972338722@winston.osd.bsdi.com> In-Reply-To: Message from Tim Kientzle <kientzle@acm.org> of "Mon, 23 Oct 2000 12:19:38 PDT." <39F48F4A.38D458C2@acm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> * ZIP access? Have you written your own, or just incorporated > pre-written libraries? The official ZIP specification puts We've written our own. > Also, have you done anything to address ZIP's relatively poor > compression? (tar.gz files are consistently much smaller than ZIP I don't think this is such a big deal anymore since disk space has quintupled while prices fell proportionately. It's a measurable difference, yes, but by no means as important a difference as it was 10 years ago. > A better approach, in my opinion, is to stick with tar.gz, but > with a slight twist: put the manifest/package definition information > first (possibly just a free-form text file and/or install script?) That sort of works (for a grotty definition of "works") but the problem is also in getting things out selectively from that point forward. Using tar.gz format, the very idea of multi-architecture "fat packages" or extract-by-property features pretty much go out the window given that you can't just apply a name-mangling algorithm and have the random-access you need to just pluck the relevant "hashed" item out. > * Consolidating package/distribution formats needs to be done > carefully. In particular, there are different security issues: > e.g., packages should generally be prohibited from dropping bits > into /bin or /etc. That's all covered under the libh security model which allows you to restrict, override or augment any of the mutagenic file primitives. > * An idea that gets floated around periodically, but never apparently > taken seriously: packages should install into private directories. > /usr/local is becoming a real tarpit. Instead, package foo-3.4 should It's not so much that it isn't taken seriously as that it's hard. A lot of software (like emacs) hard-codes its path information into the compiled binaries and makes the resulting packages non-relocatable without the services of a binary editor and a hell of a lot of luck. > * it removes the need for a temporary installation directory, > while still permitting easy rollback Roll-back should be handled by the history stack, as described in my paper. That way a roll-back of n (where n > 1) is supported to cover some of the scenarios also given in my paper. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9947.972338722>