Date: Tue, 9 Jul 2002 21:10:42 -0700 From: Jordan K Hubbard <jkh@queasyweasel.com> To: Dan Nelson <dnelson@allantgroup.com> Cc: Archie Cobbs <archie@dellroad.org>, Dan Moschuk <dan@FreeBSD.ORG>, Dag-Erling Smorgrav <des@ofug.org>, Wes Peters <wes@softweyr.com>, arch@FreeBSD.ORG Subject: Re: Package system flaws? Message-ID: <FFFB5387-93BA-11D6-AACD-0003938C7B7E@queasyweasel.com> In-Reply-To: <20020710033154.GD8625@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Oh dear, why do I find myself so unable to resist this thread? :) I agree with whomever it was that said that the "right" way to conduct this exercise would be to first define the objectives and then pick whichever package format (or invent one) which fills all those goals. We've already seen considerable debate over random access capabilities and being able to get at the "dictionary" portion of a package either by sticking it at the front or putting it in another file, so I won't go into that all over again, but I will bring up something that nobody seems to have touched on yet: Fat packages. I'm borrowing a bit of Macintosh nomenclature there (though I'm sure Terry will come along and correct me by pointing out that IBM was the first to introduce "Fat binaries" with VM/CMS or something :) but I'm sure people get the idea. If you're distributing an Emacs or TeX package which weighs in at some hefty percentage of the New York phone book in size, and with KDE and Gnome one doesn't even have to look to Emacs anymore for a good example of a "really big, honkin' package", you naturally want to save on disk space if at all possible both to minimize load on the archives and make those poor Australian users with their 9600 baud Telstra link to the US happy. Compression is certainly a good start, but when you start distributing those packages for 3 or 4 different architectures (as FreeBSD is definitely not far away from doing) you also would like to not distribute 3 or 4 different copies of the same architecture-neutral bits if you can possibly help it. That's where the idea of munging attributes into the dictionary namespace starts making more and more sense, and not just for representing different architectures but also thinks like "experimental vs stable" variants, "mix-ins" (like all the various versions of Apache which have various bits of compiled-in smarts) and what have you. If you introduce the concept of install-time attributes, some of which may be implicit (like architecture) and some of which may be explicit (like "give me the experimental version please"), you conceivably end up with mangled pathnames within the package which are demangled on the way out, C++-style. This allows you to have, say, just one copy of all the Emacs lisp files and documentation but 3 or 4 different "bin/emacs" files which don't collide internally and are properly selected for on extraction. Anyway, wish-list items like this are why it's a good idea to define the goals first and the package format second. :-) P.S. I also gree with jhb's assertion that some folks really need to take a good look at libh since it takes a number of things like this into account, including all the "occludes, obsoletes, upgrades, ..." attributes that people were recently demanding as package metadata. -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer 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?FFFB5387-93BA-11D6-AACD-0003938C7B7E>