[opam-devel] OPAM 1.3 roadmap

Peter Zotov whitequark at whitequark.org
Thu Feb 26 16:53:12 GMT 2015


On 2015-02-26 19:51, Anil Madhavapeddy wrote:
> On 25 Feb 2015, at 11:23, Peter Zotov <whitequark at whitequark.org> 
> wrote:
>> 
>> On 2015-02-25 14:20, Thomas Gazagnaire wrote:
>>>>>> I'm less sure about the viability of recording installed files
>>>>>> strictly -- I view thatas an advisory rather than 
>>>>>> enforcement-based
>>>>>> mechanism.  The reason I like the "make ~/.opam a git store" is 
>>>>>> that
>>>>>> its possible for applications to write directly into the store as 
>>>>>> they
>>>>>> do right now, but still let us track changes precisely.  In fact, 
>>>>>> if
>>>>>> we forbid subshells from writing into `~/.opam/.git`, this would 
>>>>>> be
>>>>>> a production grade solution that also offers instant-rollback in 
>>>>>> case
>>>>>> of compilation errors (no more waiting for a full recompilation of
>>>>>> the original dependencies!).
>>>> Please don't make .opam a git store. Even with one snapshot, it 
>>>> means
>>>> that my .opam would be 11G instead of 5.5G it currently is. What's 
>>>> worse
>>>> is that every recompilation or upgrade would balloon the store even 
>>>> more.
>>>> I can easily anticipate it filling the entirety of my 500GB drive,
>>>> for example. That's absurd.
>>> It's not so simple, Git uses implicit hash-consing to share as much
>>> blobs as possible, so snapshotting is free. This also means that
>>> switches will be able to share binary blobs (a long-standing 
>>> request).
>>> All of this needs to be evaluated properly.
>> 
>> I know. The issue is that reinstalls tend to change large amounts of
>> files. Imagine upgrading Core, or even worse, the compiler. Even
>> with delta compression there would be no, or almost no, sharing
>> among the biggest blobs; without it, less so.
> 
> In this situation, the git base can be rebased after a successful
> upgrade to remove the old version of the compiler and save space.
> 
> In the event of failure, it would allow for a fast switch back
> to the old working version.

Do you need git for this? You can do it with hardlinks.

-- 
Peter Zotov


More information about the opam-devel mailing list