From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q2812ANk018885
	for <caml-list@sympa-roc.inria.fr>; Thu, 8 Mar 2012 02:02:17 +0100
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhsDAEMEWE+GoCGimWdsb2JhbABDgwmCK6xmgzMBAQEBAQgLCwcUJ4IKAQEEASMVQBELGAICBRYLAgIJAwIBAgFFEwgBAReHaAWnUJIhgS+MHoIMgRYEiFCMcYVkjSU
X-IronPort-AV: E=Sophos;i="4.73,549,1325458800"; 
   d="scan'208";a="148139958"
Received: from postman2.riken.jp (HELO postman.riken.jp) ([134.160.33.162])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 08 Mar 2012 02:02:16 +0100
Received: from postman.riken.jp (postman2.riken.jp [127.0.0.1])
	by postman.riken.jp (Postfix) with SMTP id CF5B512602CD;
	Thu,  8 Mar 2012 10:02:12 +0900 (JST)
Received: from [172.27.98.103] (rikad98.riken.jp [134.160.214.98])
	by postman.riken.jp (Postfix) with ESMTPA id A7D9B1270063;
	Thu,  8 Mar 2012 10:02:12 +0900 (JST)
Message-ID: <4F580514.6050703@riken.jp>
Date: Thu, 08 Mar 2012 10:02:12 +0900
From: Francois Berenger <berenger@riken.jp>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19
MIME-Version: 1.0
To: caml-list@inria.fr
References: <35CD2569B25340E28784ABDB2505BDC2@erratique.ch> <4F577292.1070502@gmail.com>
In-Reply-To: <4F577292.1070502@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-PMX-Version: 5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.7.184819
Subject: Re: [Caml-list] odb questions

On 03/07/2012 11:37 PM, Edgar Friendly wrote:
> [...]
 >
> Except I don't intend odb to scale. It's hovering right around 500 lines
> of code, and if I can keep it around that size, I'll be happy. I don't
> intend odb to ever have a `odb remove foo` command

Hi,

Wouldn't it be possible to have 'odb remove foo' just call
'ocamlfind remove foo'?

Regards,
F.

 > nor an `odb update`.
> Maybe I'll have an `odb upgrade`, but I'm happy leaving this as `odb
> --upgrade`. Odb's goal is to be an 80% solution, and it was that a while
> ago, I think. It's approaching 90%, and I'm going to try to avoid it
> feature creeping to 100%. Oddities should be handled by the package
> installers themselves or the metadata repository as much as possible,
> leaving pretty little work for odb.
>
> E.