[opam-devel] OPAM 1.3 roadmap

[Anil Madhavapeddy]

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.

-anil