[Openmcl-devel] moving Clozure CL to GitHub

[Andrew Shalit]

Don’t forget to handle the case of someone upgrading CCL to a new version that is binary incompatible.


> On Feb 10, 2017, at 11:26 AM, Ron Garret <ron at flownet.com> wrote:
> 
> 
> On Feb 10, 2017, at 7:22 AM, R. Matthew Emerson <rme at acm.org <mailto:rme at acm.org>> wrote:
> 
>> 
>>> On Feb 9, 2017, at 10:48 PM, Ron Garret <ron at flownet.com> wrote:
>>> 
>>> 
>>> On Feb 9, 2017, at 7:39 PM, R. Matthew Emerson <rme at acm.org> wrote:
>>> 
>>>> I still have not come up with a brilliant idea to solve the problem of distributing bootstrapping images and interface databases for each of the supported platforms.
>>> 
>>> Can you explain why this is any more of a problem with git than it was with subversion?
>> 
>> Back when OpenMCL was still in CVS, the way to get a copy was a multi-step process.
>> 
>> 1. get sources (via checkout or via downloading a file, e.g., openmcl-src-0.12.tar.gz)
>> 
>> 2. get interface databases (so that stuff like (#_getpid) will work) by downloading, e.g., openmcl-interfaces-0.4.tar.gz
>> 
>> 3. get bootstrapping image (e.g., openmcl-darwinppc-bin-0.12.tar.gz) in order to have a lisp to compile the sources
>> 
>> When we switched to Subversion, we were able to do two things:
>> 
>> 1. Check in interface databases and bootstrapping binaries
>> 
>> 2. (Ab-)use externals so that it is possible to get sources, interface databases, and bootstrapping binaries in a single command
>> 
>> Subversion supports binaries fairly well: it can diff them and store deltas.  Since it's a centralized system, it doesn't matter if the repository gets large, because checking out a working copy doesn't have to copy the whole repository.
>> 
>> Git is less suited to storing binaries.  It stores them whole (i.e., it doesn't diff them), and since cloning a git repository copies the entire repository, bloating the repository with binaries is a real concern.
>> 
>> In summary, I think that having a one-command way to get a working CCL is a good feature.  I have never liked the way we abuse externals to do that, but the get-ccl-with-one-command feature seemed valuable enough that it was worth it anyway.
>> 
>> Ideally, I'd like to make it equally easy to get a working CCL when we're on GitHub.   That's what I'm trying to figure out how to do. It may be that I can preserve a one-step way to get CCL.  Or it might be necessary to a) get source and then b) get interfaces & bootstrapping image.  I'm hopeful that GitHub releases will be a good enough tool for this.
> 
> My suggestion:
> 
> 1.  Don’t store the binaries in the source tree.
> 
> 2.  Separate the initial bootstrap case from the case where someone already has a working CCL on their system and wants to upgrade.
> 
> 3.  In the case where someone wants to upgrade, write a CCL script that does the Right Thing.  Because CCL already has snarf-url built in this should not be hard.  I volunteer to write and maintain it.  The instructions for upgrading CCL should be: run upgrade-ccl.lisp.
> 
> 4.  In the case where someone is downloading CCL for the first time there are two options: either bite the bullet and make it a two-step process, or write a Python or bash script that does the Right Thing.
> 
> Personally I think making it a two-step process makes sense.  Most people approaching CCL for the first time won’t care about the sources, they will want it to Just Work.  So keep pre-built binaries on a server somewhere for first-timers and updates, and keep the sources free of binaries.
> 
> rg
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com <mailto:Openmcl-devel at clozure.com>
> https://lists.clozure.com/mailman/listinfo/openmcl-devel <https://lists.clozure.com/mailman/listinfo/openmcl-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20170210/02c9d817/attachment.htm>