On 3/22/11 14:57 , Zach Beane wrote: […]
Quicklisp has a dist preference mechanism that allows one dist's projects to take precedence over another's. You could use that to create an ABCL dist of projects for which ABCL patches have not yet been applied, and that would selectively override the unpatched projects in the primary Quicklisp dist.
I don't like the idea of interceding and patching after download very much.
I presume your objections reside from a security perspective, as an exploit that injected by such a mechanism would negatively affect Quicklisp's reputation. Is there another angle with which you have problems that I miss here?
Are you working on cryptographically signing Quicklisp packaging at all? To overcome integrity objections we would either have to securely host the ABCL distribution via SSL (this is where quicklisp.org is moving right?) or cryptographically authenticate the patches/distribution?
Do you have any idea what the bandwidth requirements for hosting such a distribution? ABCL is certainly a minority CL implementation, but we would still have to somehow scrounge bandwidth. Or could you host via the S3 quicklisp.org buckets?