Date: Mon, 23 Oct 2000 16:17:11 -0700 From: Tim Kientzle <kientzle@acm.org> To: Jordan Hubbard <jkh@winston.osd.bsdi.com>, libh@freebsd.org Subject: Re: BOF at BSDCon: FreeBSD Installer, Packages System Message-ID: <39F4C6F7.679F562D@acm.org> References: <9947.972338722@winston.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan Hubbard wrote: > > ... have you done anything to address ZIP's relatively poor compression? > > I don't think this is such a big deal anymore since disk space has > quintupled while prices fell proportionately. Yes, but CD-ROMs are still only 650MB. Are you willing to cut maybe 25% of the packages out of the CD-ROM distro? (I've seen many cases where ZIP files are nearly double the size of .tar.gz files. Have you compared ZIP and tar.gz versions of the ports collection?) And there are still a lot of people running over 28.8kbps modems; historically, bandwidth grows a lot more slowly than hard disk space. As for selective install, I'm very confused. Any streamable archive format will allow you to choose on-the-fly whether or not to write the next file to disk. If you have the manifest information up front, then you can decide on a file-by-file basis. If you're assuming that the archive is always available on a local disk (which is a requisite for single-file random access), then you're requiring a chunk of spare disk to store the package file, which I find confusing: why is a local copy of the package file so much worse than a local copy of the unpacked tree? (Which I understood to be one of your initial objections to tar.gz; to get random access, you had to first unpack it to a temp directory. Or was that purely a performance concern and not a disk-space concern?) The model I have in mind for package handling (much of which applies to distributions as well) is a three-phase model: * "Pre-install": Read manifest and installation requirements data. Among other things, this specifies which files/directories will be touched. (Having a single "package directory" simplifies this by eliminating the need to list every single file. Only files outside of the package directory need explicit checking.) It also specifies users that might need to be created, etc. Anything controversial can be verified with the user in advance; any installation options can also be settled now. * "Install": Based on options determined earlier, unpack the archived data; unneeded files are simply skipped. Streaming this is also faster than doing selective seeks and repeated single-file extractions. * "Post-Install": Some packages will have special requirements (such as editing /etc/rc.conf) This can be handled after unpacking by executing scripts in the package directory. This works very well with the idea of a "package file" consisting of manifest/installation data followed by a streamable archive. It also works nicely with the "directory per package" model. It requires no additional disk space (apart from space required for post-install scripts) either for storing the package file itself or a temporary unpacked version, which makes it very efficient for installing packages on-the-fly as they are downloaded. > > * 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 ... Huh? You have to _compile_ a program to run in /usr/local; why not just _compile_ it to run in /usr/package/xxxx/? E.g., for any program that uses GNU autoconf (which definitely includes emacs): ./configure --prefix=/usr/packages/foo-3.4 make ... <make package file> ... Then when the package is installed, it installs into the right directory and all of the compiled-in paths work just fine. As I mentioned, I used a hand-rolled version of such a system for several years; I largely abandoned it because I got tired of compiling everything myself. The 'packages' collection is a great convenience, even if I have to rm -rf /usr/local every year or two to keep the brambles down. (Yes, I really do this at regular intervals, and have since 1995 when I started using FreeBSD.) > > * it removes the need for a temporary installation directory, > > while still permitting easy rollback > > Roll-back should be handled by the history stack ... I'm not a fan of "big machinery" when naming conventions will often suffice. But, if you've already built the machinery, I suppose it's worth trying out. (Given my previous experience with "history stack" mechanisms, I'll remain dubious.) Plus, I should point out that having a directory per package doesn't rule out your "history stack". However, it does simplify it, since you don't need to track every individual file, only a single "package directory" and possibly a handful of files outside of that directory. BTW, one of my major concerns: packages must cohabitate with manually-compiled software. I've heard a lot of complaints from folks about the fact that RPM files only have "package" dependencies, not "file" dependencies. The current FreeBSD package system does dependencies much better: I can manually compile a certain library, then install a package that depends on that library without the package installer freaking out (either refusing to install or worse, overwriting my manually-built library). This is an essential feature. - Tim 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?39F4C6F7.679F562D>