[opam-devel] OPAM 1.3 roadmap

[Louis Gesbert]

Indeed, the obvious case being the consequences of e.g. the variable `ocaml-native` on the presence and installation of .cmx etc. files. All depopts potentially have an effect on installed files, which may propagate along the reverse dependencies, so computing all possible combinations doesn't seem realistic -- that's mostly why I wrote "binary repo (_with some limitations_)".

But without being too ambitious, we could already:
* compute the diff of files as they are installed on the user system (assuming, for now, that files are only installed within the prefix...)
* use a similar trick to generate .install files and push towards a wider use within the repository. Given the right tools, packagers should be able to do this.

Each of these makes the `remove:` field unneeded (and it's the one most likely to contain `rm -rf`s that could go wild)

> - Roberto Di Cosmo, 23/02/2015 20:36 -
> Hmmm... a word of warning on all this, though: the list of files installed by a
> package _may_ depend on the particular choice of other packages (and versions of
> packages) present in the system at build time.
> 
> This is not a problem for distributions like Debian/RedHat/OpenSuse etc. because
> the build is done only once to produce a binary package, that is then installed
> by all users.
> 
> Opam is not working as a standard GNU/Linux distribution right now: it is
> not binary based, and it has no notion of "release" (all version are there at
> once!), so the intuition coming from other environments we are used to may be
> misleading... the "list of installed files" may not be well defined in general.
> 
> --
> Roberto
> 
> 
> 
> On Sat, Feb 21, 2015 at 08:24:00AM +0000, Anil Madhavapeddy wrote:
> > > * Tracking of files installed by packages. While unrelated to repo signing, this might have some security implications, so we might want to bring it in.
> > <...>
> > - Registering the files that are installed is going to be quite a large
> undertaking within the repository, but also makes eventual binary distributions much easier. 
> 
> _______________________________________________
> opam-devel mailing list
> opam-devel at lists.ocaml.org
> http://lists.ocaml.org/listinfo/opam-devel