From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 728B281799 for ; Mon, 22 Jul 2013 14:20:44 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.126.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.126.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@moutng.kundenserver.de designates 212.227.126.171 as permitted sender) identity=helo; client-ip=212.227.126.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@moutng.kundenserver.de"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoDAJAi7VHU436rbWdsb2JhbABagztQrBSUHIEOFg4LCwwGFgMlgiQBAQQBDG0FCwUGGC5XBhMJCId5Cgi3C4llhX4NJgeDfgOOZRiFCYUAjlWEYw X-IPAS-Result: AgoDAJAi7VHU436rbWdsb2JhbABagztQrBSUHIEOFg4LCwwGFgMlgiQBAQQBDG0FCwUGGC5XBhMJCId5Cgi3C4llhX4NJgeDfgOOZRiFCYUAjlWEYw X-IronPort-AV: E=Sophos;i="4.89,719,1367964000"; d="scan'208";a="26872226" Received: from moutng.kundenserver.de ([212.227.126.171]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 22 Jul 2013 14:20:43 +0200 Received: from office1.lan.sumadev.de (dslb-084-059-078-221.pools.arcor-ip.net [84.59.78.221]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MXCef-1UdvMi3MHN-00VuCV; Mon, 22 Jul 2013 14:20:42 +0200 Received: from gps.dynxs.de (localhost [127.0.0.1]) by office1.lan.sumadev.de (Postfix) with ESMTP id EDFE4C00CF; Mon, 22 Jul 2013 14:20:40 +0200 (CEST) Received: from 84.107.248.22 (SquirrelMail authenticated user gerd) by gps.dynxs.de with HTTP; Mon, 22 Jul 2013 14:20:41 +0200 Message-ID: In-Reply-To: <51ECE818.9060908@etorok.net> References: <383739793.214096184.1374254520546.JavaMail.root@zimbra27-e5.priv.proxad.net> <7b4c87b5d9aa76728e239f0a2172b795.squirrel@gps.dynxs.de> <6796313D-9F02-4C70-87D9-8DC9BC896028@recoil.org> <51ECE818.9060908@etorok.net> Date: Mon, 22 Jul 2013 14:20:41 +0200 From: "Gerd Stolpmann" To: =?iso-8859-1?Q?=22T=F6r=F6k_Edwin=22?= Cc: caml-list@inria.fr User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Provags-ID: V02:K0:1VPoNF/NVK/HepdGwzc3qTy//VwnlsxaGIA4g6kPYOx xDLdy5mmF6IndZHfFG48wgTWZVdX6owt7ETvR+l0wDlllSzJTD 9hpC1LXWNuE00Jg7uJtCXlucRoa5sXZo+ZHNXXv1by+fNPAWUk rQlsLT0viNpzSZWTleB0H2kozoU42FjiIqi29rCPGEdyGk21S8 2lNJcKlOoVPaqTHOKTquEecT+ah5vqgSlONcaqBg8KFVXD1SWn kdeha2N8S21cCg4tRA8tEXg4J0T/LPQHu1v7l3gnBlToEfaMvS KM6P/EQm6bgTydtwo9q5VauT7tPPaNyYGFGT17gr0DdszmmWlx 1NArifuAsYH02GFoZzxLNTu32eUT90YgAuwC7whmWw8F8JSUHa d2NgzyfysvW4g== Subject: Re: [Caml-list] opam and godi > 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=F6r=F6k 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 --=20 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.