Hello, While this is getting a little off topic, I just wanted to correct a common misconception.
Wouter Verhelst wrote: >>I'm not sure what you mean by this; do you mean packages with circular >>dependencies which must be bootstrapped manually? If so, this is generally >>handled by our buildd admins. > > > Actually, it's handled by those that start the port. Once one version of > said package has been compiled and is available, the previous version > can always be used to build the next version. > With normal packages I agree, but what about packages like the perversion that is cmucl where the developers only guarantee that a certain release will build that release and no future one[1]? The build-procedure to get from an older to a newer release can be contrived and involve manually patching the image as it is constructed. In general one would need access to the architecture involved and then construct the new package from the binary release upstream issues. The related sbcl project can build a new release with an older version. Notice that there are more architectures supported for sbcl then for cmucl in Debian. On the upside, gcc/libc version changes cause me little or no problems :-). 1: see for example http://article.gmane.org/gmane.lisp.cmucl.devel/7925 Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
