[armedbear-devel] Patches for metatilities-base and lift
Patches to get [metatilities-base][1] and [lift][2] as distributed by Quicklisp MAR2011. We really need to either a) make our own Quicklisp distribution or (my preference) b) make a QUICKLISP-PATCH system to apply patches as QL:QUICKLOAD happens. [1]: http://detroit.slack.net/~evenson/abcl/metatilities-base-20101006-darcs-abcl... [2]: http://detroit.slack.net/~evenson/abcl/lift-20110320-git-abcl-20110322.diff -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Mark Evenson <evenson@panix.com> writes:
Patches to get [metatilities-base][1] and [lift][2] as distributed by Quicklisp MAR2011.
We really need to either a) make our own Quicklisp distribution or (my preference) b) make a QUICKLISP-PATCH system to apply patches as QL:QUICKLOAD happens.
What about c), asking the author to make changes to support ABCL? That seems like the best possible option to me. Zach
On 3/22/11 14:47 , Zach Beane wrote:
Mark Evenson<evenson@panix.com> writes:
Patches to get [metatilities-base][1] and [lift][2] as distributed by Quicklisp MAR2011.
We really need to either a) make our own Quicklisp distribution or (my preference) b) make a QUICKLISP-PATCH system to apply patches as QL:QUICKLOAD happens.
What about c), asking the author to make changes to support ABCL? That seems like the best possible option to me.
Yes, of course we will. But since QL has monthly publishing windows and getting authors to incorporate changes doesn't always happen that easily, I still think having some sort of mechanism that canonically patches QL distributions would be useful to the ABCL community. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Mark Evenson <evenson@panix.com> writes:
On 3/22/11 14:47 , Zach Beane wrote:
Mark Evenson<evenson@panix.com> writes:
Patches to get [metatilities-base][1] and [lift][2] as distributed by Quicklisp MAR2011.
We really need to either a) make our own Quicklisp distribution or (my preference) b) make a QUICKLISP-PATCH system to apply patches as QL:QUICKLOAD happens.
What about c), asking the author to make changes to support ABCL? That seems like the best possible option to me.
Yes, of course we will. But since QL has monthly publishing windows and getting authors to incorporate changes doesn't always happen that easily, I still think having some sort of mechanism that canonically patches QL distributions would be useful to the ABCL community.
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. Zach
On Tue, Mar 22, 2011 at 2:57 PM, Zach Beane <xach@xach.com> wrote:
I don't like the idea of interceding and patching after download very much.
For what it's worth, I don't like it either. For it to work reliably we'd need to keep ABCL and Quicklisp releases in sync, and tell users to update both at the same time. After all, users presently cannot use those libraries on ABCL, Quicklisp or not. If someone really needs to use them ASAP, (s)he will need to complain to the library author. Alessio
On 3/22/11 15:08 , Alessio Stalla wrote:
On Tue, Mar 22, 2011 at 2:57 PM, Zach Beane<xach@xach.com> wrote:
I don't like the idea of interceding and patching after download very much.
For what it's worth, I don't like it either.
Noted.
For it to work reliably we'd need to keep ABCL and Quicklisp releases in sync, and tell users to update both at the same time.
Keeping Quicklisp packages working with ABCL trunk and the most recent release would not be that much additional effort. As we patch ABCL to get more systems running, we can patch the packages with the necessary conditionals that call ERROR with a message stating that things won't work out.
After all, users presently cannot use those libraries on ABCL, Quicklisp or not. If someone really needs to use them ASAP, (s)he will need to complain to the library author.
With the patches [that I am seemingly accumulating][1] there is a lot of packages that can work with ABCL than is apparent from merely trying to use Quicklisp (or ASDF-INSTALL). But which patch is needed in what situation is not always that easy to tell. I try to post to armedbear-devel information about the latest version, but one might have to comb the archives to figure things out. [1]: http://detroit.slack.net/~evenson/abcl/ -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On Tue, Mar 22, 2011 at 3:18 PM, Mark Evenson <evenson@panix.com> wrote:
On 3/22/11 15:08 , Alessio Stalla wrote:
On Tue, Mar 22, 2011 at 2:57 PM, Zach Beane<xach@xach.com> wrote:
I don't like the idea of interceding and patching after download very much.
For what it's worth, I don't like it either.
Noted.
For it to work reliably we'd need to keep ABCL and Quicklisp releases in sync, and tell users to update both at the same time.
Keeping Quicklisp packages working with ABCL trunk and the most recent release would not be that much additional effort. As we patch ABCL to get more systems running, we can patch the packages with the necessary conditionals that call ERROR with a message stating that things won't work out.
For people who use trunk and update it regularly, sure. But once trunk is crystallized into a release, there will be users who won't update it at least till the next release, ~2 months later. If in the meantime a new Quicklisp release comes out, those users might not be able to use it because the patches included in ABCL could break.
After all, users presently cannot use those libraries on ABCL, Quicklisp or not. If someone really needs to use them ASAP, (s)he will need to complain to the library author.
With the patches [that I am seemingly accumulating][1] there is a lot of packages that can work with ABCL than is apparent from merely trying to use Quicklisp (or ASDF-INSTALL). But which patch is needed in what situation is not always that easy to tell. I try to post to armedbear-devel information about the latest version, but one might have to comb the archives to figure things out.
Maybe we could have a page on the ABCL wiki containing such information, updated more or less regularly. Library maintainers could be simply pointed at that page and encouraged to patch their libraries accordingly. If you like the idea, I can start working on it. Alessio
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? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Mark Evenson <evenson@panix.com> writes:
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?
It just seems like equal hassle to create and maintain a system of patch fetching and application as it is to create and maintain a system of modified archives, except the code and infrastructure to support the modified archives already exists in Quicklisp via the multiple-dists-with-preference mechanism.
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?
I'm working on using PGP to sign the indexes. The indexes include cryptographic digest and size information. There will be a CL implementation of PGP signature verification to validate the integrity of a dist.
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?
I host all Quicklisp archives on S3, and I use their CloudFront content distribution network to speed up worldwide delivery (S3 by itself is a little slow outside the USA). I have thousands of downloads per month and the storage and bandwidth costs have been less than $1/month so far. It's a pretty good deal. The dist mechanism isn't fully baked, but I'd rather you wait for an 85% solution to be finished than start a new solution from scratch. Zach
participants (3)
-
Alessio Stalla -
Mark Evenson -
Zach Beane