Re: [Caml-list] opam and godi

["Gerd Stolpmann" <info@gerd-stolpmann.de>]

> On 07/21/2013 05:43 PM, Yaron Minsky wrote:
>> While I appreciate the work that Gerd has done on GODI, I do think
>> that OPAM is a significant improvement over GODI.

Török Edwin wrote:
> opam's simplistic interface is closer to apt-get, which I use and like.
> GODI's ncurses-like interface is more like aptitude's curses-interface ...
> which I don't use.
> It also has a command-line interface, which I haven't tried (the docs
> place little emphasis on it).

It's not that much different to apt-get.

The curses-like interface is more for beginners, or getting started.

> There is more to OPAM though, 'opam switch' is definitely a useful
> feature, as is the ability to use the system's OCaml compiler (I may be
> wrong here, does GODI support that?).

Partially. You can demand a specific svn version of the compiler, and then
rebuild everything, but it's not wrapped up as command. Maybe something to
add (this would fit well into the framework).

> Having said that I would've preferred if OPAM and GODI worked together
> rather than having a completely new project.
> In the end I think what would be best is if OASIS could be automatically
> converted to OPAM, GODI, DEB and RPM packages, and then upstream projects
> would only need to worry about supplying one correct _oasis file, and
> OPAM/GODI could use that directly, so that all build/depedency etc. fixes
> eventually end up in all repositories.

Fully supporting that.

> And of course the conversion shouldn't be one-time only, whenever _oasis
> is updated the changes should propagate, perhaps with some small addons
> _oasis.debian, _oasis.opam, etc. for things that cannot be expressed in
> OASIS directly (or which doesn't make sense to have in _oasis, like name
> of downstream maintainers).
> Packagers should prefer to update these files, instead of their
> distribution-specific ones, and have the distro-specific build
> descriptions automatically generated from this.
>
> I'm aware that OASIS is not perfect either (there was a discussion earlier
> about installing docs), but I think that improving it (and the conversion
> tools) would eventually get us a simple unified build/package description
> and then library/application authors and end-users shouldn't care what
> package manager they use: they'd get a similar quality experience. And
> whenever a bug is discovered by the user of one package manager, the fix
> is applied to all.
>
> I'm aware that oasis2deb, oasis2opam exist, does oasis2godi and oasis2rpm
> exist?

There is a script for converting oasis to GODI, godi_oasis_import, which
is available now in GODI.

> How does OASIS-DB fit into this picture?

GODI even automatically imports packages from OASIS-DB into its own
repository, with nightly refresh. This is still a bit experimental, and
needs to be activated by the user in order to get the packages (described
here: http://godi.camlcity.org/godi/oasis.html).

The GODI autobuilder also tries to build the oasis packages. See the list
here (scroll down until the package names start with oasis):
https://godirepo.camlcity.org/openapps/autoui.cgi

As you can see, it is only partially successful. That's basically because
there is no QA on OASIS-DB.

> There is of course the question what to do about packages that do not
> provide an _oasis file, maybe a start would be opam2oasis (and
> godi2oasis?) that would provide a dummy _oasis file that just uses the
> custom Makefiles of the package, but provide all the metadata that the
> package does.

No, all package managers should unite in this point, and only accept
packages with oasis support. (Btw, that's homework for me.) Just do it the
same way as we did when requiring findlib.

The question here is whether oasis is already mature enough to require it.


Gerd
-- 
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.