[opam-devel] OPAM 1.3 roadmap

[Anil Madhavapeddy]

On 26 Feb 2015, at 16:53, Peter Zotov <whitequark at whitequark.org> wrote:
> 
> 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.

Sure, but that's a dead end with respect to all the other features
I described wanting a git-controlled OPAM for.  As Thomas noted, it
needs some experimentation and evaluation of space usage, but is
worth doing to see if it ends up being an effective way to do
sharing across switches and even machines.

-anil